3 ms·

> Frontend and backend must agree on every scenario When is this not the case?

by naasking 10mo ago

samtheprogram 10mo ago
When 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.
- naasking 10mo ago
  > 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.
  - nchmy 10mo ago
    To clarify, there's nothing React or SPA about datastar. Moreover, HTMX v4 is essentially Datastar-lite (but heavier, and less capable)
    - naasking 10mo ago
      There is, Datastar has client-side rendering based on signals [1]. Datastar is also very explicitly designed to be modular and extensible, so you can extend the client-side with more features, as they've done with Web Components. [1] https://data-star.dev/guide/reactive_signals https://data-star.dev/guide/reactive_signals
      - nchmy 10mo ago
        Signals aren't even really "rendering". And react and spas dont have a monopoly on doing things on the client - that's just javascript. I dare you to go to the datastar discord and tell them that they're React-adjacent, and SPA-like
- listenallyall 10mo ago
  "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.
wrs 10mo ago
I suspect the hidden assumption here is that frontend and backend are written by different people/teams with a narrow interface between them. Because they use different technologies and build tools it’s easy for them to end up being competely siloed, which IMO is one of the worst aspects of how webdev evolved in the last 20 years. Thus, it’s considered normal that the backend team spits out some JSON and doesn’t know or care what the frontend team does with it. With HTMX that distinction doesn’t exist so much (the frontend consists of fragments generated by the backend) so you will need a different organizational approach. The “frontend” folks will need to write a lot of “backend” code, but presumably in a separable layer.
- naasking 10mo ago
  It is true that htmx requires some straddling backend and frontend. I think the organizational approaches that split them is dumb to begin with personally. Good UI/UX almost always impacts the backend.

> Frontend and backend must agree on every scenario When is this not the case?

When 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.

naasking 10mo ago
> 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.
- nchmy 10mo ago
  To clarify, there's nothing React or SPA about datastar. Moreover, HTMX v4 is essentially Datastar-lite (but heavier, and less capable)
  - naasking 10mo ago
    There is, Datastar has client-side rendering based on signals [1]. Datastar is also very explicitly designed to be modular and extensible, so you can extend the client-side with more features, as they've done with Web Components. [1] https://data-star.dev/guide/reactive_signals https://data-star.dev/guide/reactive_signals
    - nchmy 10mo ago
      Signals aren't even really "rendering". And react and spas dont have a monopoly on doing things on the client - that's just javascript. I dare you to go to the datastar discord and tell them that they're React-adjacent, and SPA-like
listenallyall 10mo ago
"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.

wrs 10mo ago

I suspect the hidden assumption here is that frontend and backend are written by different people/teams with a narrow interface between them. Because they use different technologies and build tools it’s easy for them to end up being competely siloed, which IMO is one of the worst aspects of how webdev evolved in the last 20 years. Thus, it’s considered normal that the backend team spits out some JSON and doesn’t know or care what the frontend team does with it. With HTMX that distinction doesn’t exist so much (the frontend consists of fragments generated by the backend) so you will need a different organizational approach. The “frontend” folks will need to write a lot of “backend” code, but presumably in a separable layer.

naasking 10mo ago
It is true that htmx requires some straddling backend and frontend. I think the organizational approaches that split them is dumb to begin with personally. Good UI/UX almost always impacts the backend.