Draft: understanding htmx

Biff
1

Next up on the content library roadmap is an essay which I’m calling “understanding htmx.” I’m going to experiment with drafting the essay in sections here on the forum. Feedback and ideas are welcome. I’ll keep the entire draft in this post and add separate replies listing the edits I make.

[Edit: removed draft. Final post is published here: Understanding htmx]

1 Like
2

[edit: moved the content of this post into the OP]

3

That’s it for tonight. A rough outline for the remainder:

Mental model

  • you’re not building an htmx app, you’re building a server-side rendered app with htmx.
  • Server-side rendering (thin client) simplifies the programming model but puts a ceiling on the user experience. SPAs (thick client) are more complex (distributed state) but have a higher UX ceiling.
  • If server-side rendering is good enough for your app, that approach will tend to take less effort than building a SPA.
  • htmx expands the number of cases for which server-side rendering is good enough

Tips for learning htmx

  • Start without htmx—just do regular server-side rendering. If a plain-old-form + full page reload is fine, just use that. no need to do hx-post every time you make a button.
  • When you hit limitations, then think about how htmx might help. Take a look at the examples.
  • It’s fine to use some javascript! expected, even! htmx is just meant to reduce the amount of javascript you have to write; not eliminate it.
  • htmx goes especially well with drop-in JS components, like this one.
  • After you’ve been doing htmx for at least a little while, I hear alpine.js pairs well with it. alpine lets you inject some reactivity into your server-side rendered html. (that being said, I’ve gotten pretty far myself with just htmx and a bit of custom JS + hyperscript.)
  • You can even try writing your own custom JS to do html snippet fetching/swapping instead of using htmx, as a learning exercise if nothing else

Should you use htmx (or rather, server-side rendering with htmx) for your app?

  • if you get to the point where you’re starting to store state in javascript instead of leaving it in the DOM, that’s a good sign you might be ready for a SPA.
  • If there are a bunch of dependencies between different parts of the page (like a spreadsheet) you probably need a spa
  • complex forms (like in an enterprise saas app) might also be a pain in htmx (?)
  • if you like to spend most of your time in the backend and don’t consider yourself to be much of a frontend dev (:person_raising_hand:), you’ll probably love htmx
  • if you’re already productive and happy writing SPAs, might as well stick with that—you probably aren’t missing anything
4

Beyond the scope of serious evaluation for any individual frontend project I think there’s definitely merit in reflecting on how the industry can push the limits of “hypermedia” forward. HTMX is particularly attractive to me because of that promise. No need to cram that into your article though :slight_smile:

1 Like
5

I think something along those lines would be worth mentioning! e.g. about how there are other approaches to modern server-side rendering (hotwire, phoenix live view, I think there’s something in php land too…); I.e. there is some larger industry momentum in this direction. biff’s also not the only framework to do thin client by default, there’s also a little framework called Rails :wink:

Fly.io also is really interesting for the possibilities it opens up here–deploy on the edge without having to write your app as a bunch of serverless js functions

6

That’s a good one! I think I approached this from the other way at first and over-complicated things a bit.

1 Like
7

Added this to the end of htmxwhat?:

That’s a minimal example of what htmx can do. A few other important features:

  • You can put hx-post (or hx-get / hx-put / hx-delete) on other elements, like individual inputs, not just forms.
  • You can use hx-trigger to change the event that triggers the request, such as click, change, or load.
  • hx-target lets you specify where the response body should go, using a CSS selector (e.g. #output or closest div).
  • With hx-swap you can change the way the response body is inserted into the DOM, e.g. set it to beforeend to insert something at the end of a list.

htmx takes the standard HTML behavior of “when the user submits a form / clicks a link, send an HTTP request and load a new page” and generalizes it to “when [something happens], send an HTTP request and put the response [somewhere in the DOM].”

Though maybe I should put that at the end of Why not just re-render the whole page? instead…

1 Like
8

Moved the entire draft into the OP so it isn’t split across multiple posts, and started writing up another section.

9

Just finished the how to think about htmx section and finished up with an is htmx right for you? section. The draft is now complete. I’ll probably let it marinate for a bit, making any edits that come to mind, and then publish it sometime next week.

2 Likes