Last year, I built an event registration tool for our district, mainly to keep track of what professional development we were doing and try to get paper out of the workflow. I chose to use Flask and Svelte for this project and this year, I decided to move away from Svelte and rebuild the application using HTMX. In this post, I’ll explain why I decided to make the change and highlight some situations where HTMX just makes more sense for a large app managed by a single person.
Making a Switch
I had tried taking a dive into React, Meteor, and Vue, all with little or no success. The complexity of the frameworks and the abstraction needed to get stuff to show up on the page went way over my head, especially as a hobbyist. Adding complexity was the requirement to use build systems (I know Vue can be added directly with script tags, but that’s not where I was introduced to it) and those felt untouchable.
I had a published version of the registration site by fall 2021 and it worked well for a first “real” project. Python did the heavy lifting in the background and I was able to have a nice interaction on the front with Svelte. So, why the move?
There are two main reasons:
With those issues in mind, that’s why I decided to move to HTMX.
How is HTMX Different?
This provides instant benefit in several ways:
- The client no longer has to manage state. The server already knows the application state, so why not just send content that is stateful based on the user session (ie, logged in vs not logged in)? Using Flask sessions makes this very simple.
- Templating engines can still be used for dynamic content creation. Each template contains the content it needs and doesn’t have to re-wire itself with the other items on the page once it loads.
- Each request returns everything the user needs. You’re not required to make more network calls to get the data necessary for the view or template (I think that’s what “hydration” is).
With any Create/Read/Update/Delete (CRUD) tool, form rendering is a common task. I want to dive into the difference between doing this in Svelte and HTMX as an example of why I decided to make the move.
In Svelte, I created a
FormWrapper component which would dynamically handle input element rendering and form submission. This pattern was extremely helpful and I actually took some of the principles I learned and applied them to HTMX. The snarls came in determining what actually needed to be rendered.
A simple example is this view: when the user clicks on one of the action buttons, a form is rendered. Depending on the action, the form is different. In Svelte, you need to first render the form and then fetch the fields – two network calls to render. It works this way because Flask is serving JSON – agnostic structured data rather than data which carries all the information it needs in order to render.
Svelte form wrapper
So, a couple hundred lines of code to render a form. Reusability is good, but when it came to editing a form, it got gnarly really quickly. The main drawback was that for the form to even render, it required several more requests to the backend to get the fields necessary. Because the backend was just a JSON cannon, even the data it returned needed to be mapped and filtered into a usable state.
HTMX form rendering
With HTMX, that form is pre-templated and then sent from the server. Instead of a single endpoint to return all the form data, individual endpoints can be used to send back whatever form is necessary in HTML. There is no needed to request more information or process the data in the client to make it usable.
Because of Flask’s templating engine and thanks to the extremely helpful Jinja partials extension from Michael Kennedy, I was able to mimic the dynamic action where a temporary sidebar is used to load and display the form.
The obvious tradeoff is that there are more files to maintain. But because each file is single-purpose, they’re smaller and more focused, which means maintaining is much easier. It’s also much more clear what is being returned by each operation rather than firing the JSON cannon and then untangling everything on the client.
HTMX’s approach to adding functionality via HTML attributes is much closer to the surface of normal web structure and gives just as much flexibility for 99% of what I need to do at a much lower complexity. I just enjoy working with HTMX because I can spend less time trying to figure out where an emitted event goes to make an update and more time making the tool more useful for my colleagues. That’s a win every time.