alt Hacker NewsWhen an API returns JSON, your JS framework can decide what to do with it. If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place. Hence why they said endpoints can return 3-5 different versions of HTML.
Replies
"framework can decide what to do with it" sounds like a feature (more flexibility) but is actually often the source of errors and bugs.
A single, consistent, canonical response, generated by the server, taking into account all relevant state (which is stored on the server) is much cleaner. It's deterministic and therefore much more testable, predictable and easier to debug.
For pure UI-only logic (light/dark mode, etc) sure you can handle that entirely client-side, but my comment above applies to anything that reads or writes persistent data.
> When an API returns JSON, your JS framework can decide what to do with it.
The JS framework is the frontend, so you're still coordinating.
> If its returning HTML that's intended to go in a particular place on a page, the front-end has far less flexibility and pretty much has to put it in a specific place.
Well yes, because presumably that's what the app is supposed to do. If it's not supposed to put it in that place, why would that be the specified target?
If this kind of static assignment of targets is not flexible enough for some reason, then use OOB updates which lets you replace fragments by id attribute. That lets you decouple some of these kinds of decisions.
Although "endpoints can return 3-5 different versions of HTML" is also a bit of a red flag that you're not using htmx correctly, generally endpoints should be returning 1, maybe 2 fragments in unusual cases.
In any case, you might find DataStar more to your liking, it's partway between React and htmx.