Not really, as long as you keep your HTML-driven interactions from becoming too fine grained.
For example, if you have a search page that provides management of contacts + active search & click to load functionality, it might look like this:
GET /contacts - get a list of contacts + search & click-to-load functionality
POST /contacts - create new
GET /contacts/:id - get the details for the contact
PATCH /contacts/:id - update the contact
PUT /contacts/:id/archived - archive the contact
DELETE /contacts/:id - remove the contact
All pretty reasonable and all can reuse the same few templates and sub-templates for rendering responses.
Thank you. To continue this conversation, how would one implement searching and filtering? My use case is an online ecommerce store (think amazon.com or newegg) where you sell multiple different categories of items. For example, if someone searches for SSD, we should show a list of checkboxes to filter by capacity such as 1 GB or below, up to 127GB, ... (based on inventory and other business requirements). How would I do that?
In your example, we can say something like if you could grab lists of by contacts by some common trait such as employer or domain of email address?
You'd have category pages with different filters. E.g. for the 'Storage' category you'd have, among others, the 'capacity' filter. HTMX doesn't take over your entire render like a SPA. It affects targeted areas of the page. E.g. when you would select the '<1GB' checkbox and click 'Filter' on the left panel, that's where HTMX would step in, to swap in the response of calling the 'search' endpoint with the current filter params, e.g. '/search/storage?capacity=<1GB'.
For example, if you have a search page that provides management of contacts + active search & click to load functionality, it might look like this:
All pretty reasonable and all can reuse the same few templates and sub-templates for rendering responses.