Automasean

HTMX is a lightweight (I believe 14K) JS library that facilitates HATEOS. This library has no dependencies 🤯

After building a notes/reminder application with Astro and HTMX I have some takeaways.

Observations

Some fairly simple features that can be built in short order by a library like React are not trivial with HTMX.

For example, it's not as simple as you may think to replace DOM elements back and forth when the replacement relies on JavaScript. In the GIF below you can see that I cannot click the "..." button again after canceling the form.

Six images of 4 strands gradually becoming more intertwined

This could be user error, there are probably techniques I don't know about. This is also partly an Astro integration issue but I think you'd come across similar limitations with other frameworks.

To fix this type of issue, I use a MutationObserver to watch the parent element for DOM changes. When the page updates I re-register my event listeners.

Other observations:

  • XSS considerations if your backend framework doesn't offer XSS protection/sanitization
  • Scenario: you want to update multiple areas of the page as a result of user interaction
    • swap the closest common parent
      • pros: simplest
      • cons: performance isn't great for large parent elements
    • out of band (OOB) update
      • pros: one network request
      • cons: a bit more complex
    • trigger an event and have consumers listen
      • pros: opt-in to the event
      • cons:
        • a bit more complex
        • more requests over the wire
  • Contrary to popular belief, I think you could use HTMX for large projects
    • you'd need to establish patterns and have a team of disciplined developers
    • over time you could build tooling to automatically enforce patterns

Pros

  • The juice is worth the squeeze having most of the state living on the server.
    • I could probably write a whole post on this. I guess I didn't realize how complex synchronizing client and server state is until I didn't have to anymore.
    • The only state on the client is purely presentational (e.g. expanding/collapsing accordions).
  • "Lightweight" is an understatement when comparing to a React app.
    • Removing the time spent downloading a relatively massive JS bundle is very noticeable.
  • For the most part, HTMX works well with Astro, especially after page partials were introduced.
  • HTMX lazy loading support is simple and powerful.

Cons

  • Lots of chatty network calls.
    • This is not great for offline-first apps, but what is?
  • Accessibility doesn't seem to be the highest priority.

Overall thoughts

After using "modern" client technologies for almost a decade it's definitely a shock to the system learning HTMX. I found I've needed to fundamentally change the way I think about building my client and API layers.

Development feels very UI first vs API -> client. API design kind of feels like GraphQL schema design in that sense. Only give me what I need as the client. If what I need changes, the schema changes.

In this age, the pendulum is swinging back to simplicity - made possible by browsers adding native support for more and more.

My application feels very snappy. It's extremely nice not to have so much JS bloat.