author, Laurence Isla,. This how-to shows a way to return HTML content and use the htmx library to handle the AJAX requests. Htmx expects an HTML response and uses it to replace an element inside the DOM (see the htmx introduction in the docs). Preparatory Configuration: We will make a to-do app ...
Ok…
That’s AJAX.
Is that a good thing?
That one is interesting… but kind of flies in the face of any adblockers or client-side content modifiers. What happens when the target for a response got removed from the DOM by the client?
Direct database access with no input sanitization?
Using database functions for running application logic? Every backend developer now needs to be a DBA?
What about error handling? Doesn’t it expose too much of the internal structure?
Hm… it sounds to me like all versioning inherits the caveats of schema migrations, am I missing something?
Yes, and that’s what is shown in this article.
htmx is not meant to do anything fancy that you can’t do with Ember/Angular/React/Vue/etc.
htmx is simpler though and has a few benefits as I see it, compared to those frameworks:
No duplication of data models and routing, and all business logic stays on the server-side where it belongs.
No build step, no dependency hell, and no outrageous churn; just include one JS file that browsers should be able to run indefinitely.