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 ( :
I haven't worked with Thymeleaf; I used to do SSR using #JSP and later #Freemarker.
As for natural templating: I expect it to make my fragments more clear when the serverside directives are explicitly not in the HTML, like with JTE, whereas the clientside directives are, as HTMX. Less confusing than when clientside and serverside logic are both inline in the same HTML template.
If in #DassaultSystemes they would hear about #HTMX and rewrite that hot mess of #3DEXPERIENCE#Enovia, perhaps, the product itself and modifications from partners would become worthwhile... We have long outlived iframes for emulating #SPA environment.
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
Would be sweet if I can have a static #HTML / #CSS website that uses #HTMX for interaction with a backend written in Kotlin and compiled to #wasm running on an edge location using #wasi .
Also, not immediately relevant to your current issue but something that might be worth considering for the future: using the htmx websocket extension, you can basically implement a streaming HTML approach (example using Kitten: https://ar.al/2024/03/08/streaming-html/) where you can just stream errors to the page as they happen.
@quii Just stumbled on your post and found you on Mastodon. Excellent write-up!
I remember visiting frontend conferences where people were struggling to explain the value of progressive enhancement. Then one year, the frontend movement discovered AngularJS and from there every few months a new SPA thing emerged to solve the mess the previous incarnation left behind.
I am so glad #HTMX is catching on with full stack developers.