imo any experienced frontend framework person will be able to pick out the issues with this impl. OP is returning entire strings of HTML (App, Todo, Icon) to rerender on state changes. this works when 1) you dont care about keeping UI state on the parts that are replaced (incl any stateful children of the UI element that happen to be there in your DOM structure), and 2) when you dont have to update the app in any other places when your state changes. go ahead and build your whole app by replacing innerHtml, frontend frameworks will be right here when you get back from speedrunning the last 10 years.<p>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.<p>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 ] (<a href="https://overreacted.io/optimized-for-change/" rel="nofollow">https://overreacted.io/optimized-for-change/</a>). 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)<p>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.<p>happy to revisit my opinion if there are componentlike design patterns in htmx i am not aware of.<p>*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)
I am a backend/ML engineer and tried using HTMX to create a website with:<p>* Search box<p>* Typeahead<p>* Instantly updating search results<p>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 see a couple of people here bashing on the practicality of this project. That's obviously not the point, it's an interesting weird use case that's more explorative/educational than practical. I thought it was an interesting and inspiring read!
FWIW, as a hobbyist developer who never had a chance to learn React, I found HTMX really helpful to make my Flask projects more reactive without adding much complexity.
IME, Htmx is best for enriching server side rendered (non-SPA) apps. I'm having an great time with single file web apps using FastHTML (python).<p>I've rewritten a bunch of my JS framework apps for simplicity and don't miss much.
I'm not sure about this approach but it does look interesting. I think it'll work fine.<p>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.<p>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.
I don’t know if the article describes the best use of HTMX, but when I wanted to experiment with building an interactive physics application on the web that used Julia on the backend, it was a perfect fit. I could design the whole page without any javascript (almost):<p><a href="https://lee-phillips.org/pluckit/" rel="nofollow">https://lee-phillips.org/pluckit/</a>
I hope we build Single-page apps with iFrames one day like how the web originally used <frame>. Everyone only talks about iFrames as if their only purpose is cross-origin content and <frame> is forgotten.
It's already bad enough that too many devs think only in SPA mode, now you're trying to use the wrong tool for the wrong solution !<p>Fun experiment though, in the true "hacker" spirit ;-)
I made a somewhat similar prototype by mocking XHR instead of service workers, in <a href="https://stackblitz.com/edit/typescript-h3wfwx?file=index.ts" rel="nofollow">https://stackblitz.com/edit/typescript-h3wfwx?file=index.ts</a><p>It was fun for a bit to quickly experiment with how htmx works, but I find it difficult to scale in terms of state.
HTMX is an idea that I never understood. HTML over the wire sounds like the most egregious idea I could have ever thought of. If you want a sub par SPA experience just build an SPA with PHP ;), and if you want a real SPA that doesnt have 600 ms of latency when I click a button that for some god forsaken reason calls an api endpoint, use React or Vue or Svelte like we always have. Is it perfect? Trust me, as someone who is trying to build something that delivers an actual SPA experience with SSR without Node.js, it's not, but a real SPA is miles better than streaming HTML over the wire.
For my own hobby useage - ie apps I shared with a few people - htmx is a godsend. It lets me focus most of my time in python/flask.<p>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.<p>I'm just thankful I don't have to dive into JS frameworks and can mostly stay in html, maybe a little hyperscript.
imo htmx is good but its a bit too low level to use directly, you sort of have to rebuild all the features frameworks like React have, such as components in your server programming language.<p>I'm building <a href="https://htmgo.dev" rel="nofollow">https://htmgo.dev</a> to do that with go + htmx, and <a href="http://fastht.ml" rel="nofollow">http://fastht.ml</a> seems like a good contender for python
<i>"Your scientists were so preoccupied with whether they could, they didn't stop to think if they should"</i><p>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's sucks man who even uses this useless thing
btw <a href="https://swag.htmx.org/products/htmx-sucks-mug" rel="nofollow">https://swag.htmx.org/products/htmx-sucks-mug</a>
Anyone who says React has mired developers in complexity needs to go back ten years and use jQuery to build a single-page app and remind themselves how much less complex React is. I know that because I rewrote a jQuery-based SPA in React back in 2015 and that experience was so revelatory that I will never forget it.<p>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.<p>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.