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 ...
htmx extends and generalizes the core idea of HTML as a hypertext, opening up many more possibilities directly within the language:
Ok...
Now any element, not just anchors and forms, can issue an HTTP request
Now any event, not just clicks or form submissions, can trigger requests
That's AJAX.
Now any HTTP verb, not just GET and POST, can be used
Is that a good thing?
Now any element, not just the entire window, can be the target for update by the request
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?
PostgREST
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?
provides a natural way to do API versioning
Hm... it sounds to me like all versioning inherits the caveats of schema migrations, am I missing something?
I feel like most of the things such as dependency hell and at least some amount of data models and routing can be resolved by using custom elements tho. I can agree to a certain point that HTMX could lead to a simple markup based approach, but it's still a matter of learning another library and all that junk. In a perfect world I feel like there should just be an equivalent to maybe the `` element that could on becoming visible makes an Http call to lazy load and plop in some inner HTML. I guess you'd still be missing the whole events driven by attributes part tho.
I don't know if I think this whole HTMX stuff is silly cause I'm jaded, or don't see a use case for it personally. So take my comment with a huge grain of salt.
PostgREST is pretty cool but I can never figure out a use case for it. You want something that's not too cold, doesn't interact with other systems, and it's worth it the additional security effort for configuring postgres.
I think people also widely misunderstand how it works, which doesn't help if course. It's not just a database you can access on the internet, there's a while bunch of security you set up first, and it uses the native row based security features to separate users' data.