Yes! HTMX is a better API on top of a XMLHttpRequest for this approach. A hypothetical next iteration of the HTML standard could make most of HTMX unnecessary. Maybe one day.
Usually we have a base template with a content block that a child template can extend. The extend keyword supports variables as well. So we can create a dummy base template, e.g. fragment_base.html, that contains only the content block and if a request is coming from HTMX we set the base template to the dummy one, so the rendered template will contain only the fragment.
It's already supported with the client-side-templates extension [1]. HTMX can fetch JSON from the backend then calls e.g. nunjucks.render() with the data.
Not at all, you can preload as many data as you wish and use vanilla or a companion JS framework like Alpine.js or HyperScript or any web-component to make the current page interactive without fetching the backend. It's a trade-off between the initial page size vs. additional network delay.
HTMX is basically a JavaScript framework that makes the traditional request-response approach feels like an SPA via replacing only part(s) of the current page with the response. In this case: it loads a small form, submits it to the backend, then replaces the respective part of the page with the updated markup. The state is kept only at the backend.
With some constraints you can create a page that works with or without JS. The same endpoint can be used for serving HTML fragments for HTMX and full page for JS-disabled clients since the HTMX request can be detected by the HX-Request header.
Because they are actually two distinct views: one is a details view, the other one is a form view. HTMX loads the form view and replaces the respective part of the page. But it needs to contact the backend for the form, you don't have the data model on the client like with an SPA framework, so you cannot generate the form.