I used #htmx in Bone Health Tracker to edit & update the dexa scan report data reactively, without having to import a million JavaScript libraries.
FAANG companies made their web development challenges everyone else's problem as well by promoting overly complex, over-engineered libraries and frameworks.
99.9% of the websites wouldn't need to show a animated like counter getting updated reactively and if we do; we now have htmx.
I'm only just finding my way in the land of #htmx, but it feels like "trigger a request from any #HTML element" is a trap. I want progressive enhancement, which still requires a functional non-Javascript page before adding the nice things htmx offers. I didn't realise how rusty I am with regard to designing a presentation layer for all this in the backend.
In 45 minutes I made a #kotlin#javalin application from scratch, which uses #webjars to include #htmx from a #maven pom file. It uses static #HTML files for the first load, and then renders HTML from #jte templates for #SSR of the parts of the pages that need that kind of interaction. There's no #springboot (or any #spring at all) and no #SPA like #angular or #react.
Now because simply setting up a project says close to nothing about its real world viability, next step is an actual usecase ( :
Sometimes, when I talk to frontend developers about how #HTMX requires you to have more presentation awareness in the projection side of your server application as you generate content in HTML, which in the #Java world is pretty much what we did with #JSP, Freemarker and Thymeleaf, I'm met with amazement.
No dis, but be aware: There's a generation of capable professional frontend developers who don't know backend servers can serve HTML just fine, and not just Json over HTTP.
Can't recommend enough the Hypermedia Systems ebook to web developers. Not only a great resource for learning and "getting" #htmx, and acquiring key best practices for using it, but it also makes the case for the classic #hypermedia system architecture, which has been somewhat disregarded over the last decade or two. Should be a worthwhile read, regardless of the framework or app architecture you intend to use. https://hypermedia.systems/#webdev#html
This is a great rapid-fire intro to #HTMX. Too fast for good retention of course, but a great way to survey HTMX capabilities and style in 8 minutes. https://www.youtube.com/watch?v=TT7SV-bAZyA
#htmx tip: if using "htmx.ajax()" API call to trigger an HTMX request, and you need to push the URL to your history, return response with "HX-Push-URL". (django-htmx has a handy "push_url()" function for this).
I made a ServiceWorker intercept #HTMX calls and manage state inside of the ServiceWorker process all in-browser.
The downside is it takes a few seconds for the service worker lifecycle to start, so it's likely only available on page refreshes. Still a neat concept.
Every few months, I come back to rewriting a #todo app in #aspnetcore, sometimes it's with Blazor, sometimes it's Razor Pages, and this time with #Htmx (although I may have already done HTMX 😅)
I got some quality-of-life improvement issues entered to help make #JetBrainsRider better, too. So that's a win!
Modern React.js with Vite is really nice, with out of the box TypeScript support and all, but by far my favourite text stack is most likely #php with #htmx. It's the simplicity that gets me.
Some nice feedback on django-template-partials on the hellsite.
Translated from the French:
> A package that helps me organize my templates in my #Django and #HTMX projects is django-template-partials from @carlton. This is the library that has had the most influence on my code in a long time.
Usssh, now I’ve done it. I actually have to talk about htmx and blazor next monday. So I need all you folks help, what are the libraries you are using? What are the good and bad things about that combo?
Doing a talk at lunch today covering how to improve #ASPNET#RazorPages with #HTMX. I have to give this talk a few times in 2024 at conferences, so it's a great way to improve the content before then. Wish me luck!
Using #htmx in my apps has let me turn the "no logic in HTML templates" all the way up to 11.
I am now very aware (and suspicious) of any logic being evaluated, or even things like string concatenation, being done in HTML templates.
I may have to write a tool to warn me (or fail a test!) if I start using th:if, th:unless, or anything that looks like a method call in my Thymeleaf templates.
After a bit of playing with #FastAPI, I feel like it's really, well, API-oriented. You can have templating of course, but it's just a liiiittle clumsier than returning JSON (e. g., you need to manually inject the request into it).
So I'm not entirely sure if I should stick to my original plan of mostly rendering HTML and using #htmx, or if I should go with the framework flow and make a #Vue app. Probably the latter TBH.