420 words, 3 min read
⚠️ This post links to an external website. ⚠️
Ever since I learned about htmx a few months ago, I’ve been hooked on it. It unlocks richly interactive and performant web app designs without making you write a single line of your own JavaScript, and without a byte of client-side state (outside of the DOM and maybe a session, of course). Its philosophical underpinnings are also convincing: the browser is a powerful tool for rendering and navigating complex interfaces, and when your server is responding to HTTP requests with HTML, like in the old days, you can eliminate several layers of complexity from your application stack.
I remember a conversation with some co-workers as we were brainstorming how to address a performance issue. Our R…
420 words, 3 min read
⚠️ This post links to an external website. ⚠️
Ever since I learned about htmx a few months ago, I’ve been hooked on it. It unlocks richly interactive and performant web app designs without making you write a single line of your own JavaScript, and without a byte of client-side state (outside of the DOM and maybe a session, of course). Its philosophical underpinnings are also convincing: the browser is a powerful tool for rendering and navigating complex interfaces, and when your server is responding to HTTP requests with HTML, like in the old days, you can eliminate several layers of complexity from your application stack.
I remember a conversation with some co-workers as we were brainstorming how to address a performance issue. Our React frontend was requesting a lot of data from the backend. Someone asked “without that data, how will we know what the user has permission to see?” It suddenly became clear to me: the server knows what permissions the user has, and it knows what the user wants to see, why are we involving another system in this operation? Heavy client-side state does not solve any issues, it is only a futile exercise in synchronizing distributed state. The only place that your data is “correct” is in the database, so the server should produce the corresponding HTML and be done with it! This quote from intercooler.js sums up this idea perfectly:
In an ideal world you would give your UI developers everything they could possibly need to build their UI efficiently: an open and expressive query layer that would let them tune the structure and return data of a query just so for those hot, complicated queries that always end up dominating system performance.
But what if I told you that a place exists where you can do this?
Such a place does exist.
This place is called… the server side.
Whether or not you agree with this approach, I still suggest that you take a look at a few of the articles on htmx’s essays page. They answered my questions and soothed my concerns while teaching me the magic of the HOWL stack. (HOWL stands for “Hypermedia On Whatever you’d Like,” a tongue-in-cheek way to say that any tech stack capable of producing HTML can easily use the hypermedia approach.)
I’ve built two applications with HTMX so far. Both apps use Elixir’s Phoenix framework as a backend. Overall, it’s been a delightful experience, and it has made full-stack work fun for me again. However, there are some rough edges I’d like to knock off.
If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe use the RSS feed.