Building a Single-Page App with Htmx

in other words, this todo app is just about the most complex of a frontend you can easily* build with htmx, i'm afraid. try to fix either 1 or 2 and you end up building components and your own little framework.

as an exercise to demonstrate, try taking OPs code and adding a count of todos on each All/Active/Completed tab that should update every time u add/edit/delete the todos. see how much extra ui code that takes. compare with equivalent [framework of choice] impl (in most it will just involve 1 state update, thats it). this is htmx's explosion of complexity that makes it not [ optimized for change ] (https://overreacted.io/optimized-for-change/). code that is hard to change eventually calcifies and consumes code that is easy to change if you do not consistently garbage collect (nobody does)

i bought the hype too until i tried building something nontrivial in htmx and im afraid the aforementioned islands of interactivity you can build are very very smol islands indeed.

happy to revisit my opinion if there are componentlike design patterns in htmx i am not aware of.

*emphasis on easily; with enough elbow grease u can do anything ofc. but then you fall out of htmx's very narrow [ pit of success ](obligatory codinghorror dot com link)

* Search box

* Typeahead

* Instantly updating search results

It was super instructive. In the end, I realized HTMX was probably not the best tool for that job, but it really helped me bridge the gap between "I get in theory why we use JS on the FE" and "Ah, I can see why client side JS is the obvious choice for this".

I've rewritten a bunch of my JS framework apps for simplicity and don't miss much.

My method is however to use Django and templates to build a regular MPA, and then switch out link changes (between pages) with htmx functionality so there is no browser reload. At least then you'll have a webapp that acts mostly like an SPA.

Next up, you can add more interactivity using htmx as much as you want (with some kind of Django components, ideally). You can even add VueJS to one of the pages if you want, but full blown SPA frameworks tend to eat into development time, so rather not unless absolutely needed.

https://lee-phillips.org/pluckit/

Fun experiment though, in the true "hacker" spirit ;-)

It was fun for a bit to quickly experiment with how htmx works, but I find it difficult to scale in terms of state.

I do have a slightly more complicated TTRPG live character sheet that I use for a game I run. Its got five users at once and sqlite backend. Its gotten moderately more complicated over the last year and now sports htmx, discord integration, and will soon have SSE for me to push events to their character sheets, like ability point refreshes etc and other fun stuff without them having to refresh the page all the time.

I'm just thankful I don't have to dive into JS frameworks and can mostly stay in html, maybe a little hyperscript.

I'm building https://htmgo.dev to do that with go + htmx, and http://fastht.ml seems like a good contender for python

At that point, maybe stop fighting with service workers and simply use a framework like Vue. It allows html templates to be swapped in, in much the same way. Except you can actually debug it and store in localStorage if you desire.

It is then that they will realize complexity comes from single-page apps. Pushing back against that complexity should result in not building SPAs, which is where Htmx comes in. There are still plenty of very successful web apps that are not SPAs.

If a product owner asks to build a SPA, a developer's job is to stop and ask why. Most likely what the product owner really has in mind can be accomplished without a SPA.