6 ms·

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at

by stefan_ 10mo ago

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere.. Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full React fancy component lib SPA that is eventually just compiled down to a zip bundle of files that the backend needs to know nothing about and can serve as dumb files. The backend is a JSON API of sorts that I would need to build anyway for other use cases.

ErroneousBosh 10mo ago
> It's terrible, why would I want my endpoints to return random HTML fragments? What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).
- stefan_ 10mo ago
  HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.
  - ErroneousBosh 10mo ago
    Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.
    - leoedin 10mo ago
      I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment. The only exposure the back-end has to HTML is streaming the static files to the browser. Which can be done in small chunks. If your back-end is rendering HTML with every request, it has to do a lot more work. It has to load HTML templates into memory and insert strings into them.
      - goodpoint 10mo ago
        This is plain false.
      - ErroneousBosh 10mo ago
        Okay, so how do you actually show the stuff to the end user? Just raw structs of data? Or do you turn that back into HTML? Now you've got two sets of templates to cope with... Why would I care about how much effort it is for the server to generate? It's already generating HTML from templates, and it's more-or-less infinitely capable of doing so.
      - bccdee 10mo ago
        > It has to load HTML templates into memory and insert strings into them. In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.
        stefan_ 10mo ago
        Three levels down and people have entirely forgotten what my post was. My "server" is some anemic ARM core built into real physical hardware with 64M of read-only storage. I don't want it spending its time "hydrating" some DOM, I don't want to bring any of this frontend insanity on there at all. No code hosted on npm shall ever run on that processor or I can't go to sleep in peace. So how do we still get a fancy SPA website? Build it all down to a simple zip bundle, the ARM can serve those static files just fine. The SPA talks to the ARM via a few JSON APIs. Very nice clean boundary.
        listenallyall 10mo ago
        Yes, if your server is a weak, limited processor, you want to keep the demands on it as low and lean as possible, and let the client do the heavy lifting. HTMX is not a good fit for this scenario, just like PostgreSQL is not a good database to embed on your devices. This isn't a controversial idea and nobody would try to sell you on HTMX for your use case.
  - wrs 10mo ago
    I don’t get what you’re saying (maybe there’s a typo). With React, generating HTML on the embedded device is exactly what you’re doing — twice (virtual and real DOM).
drcongo 10mo ago
The HTML fragments aren't random.
bottlepalm 10mo ago
Returning HTML sounds like a styling nightmare, if anyone changes the structure, unintended consequences. Plus it’s difficult to reason possible states of the UI with fragments sitting on the server, possibly dynamically built on the server. Very jquery/PHP ish. I had my fun and don’t want to go back.
- robinhood 10mo ago
  Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.
  - bottlepalm 10mo ago
    I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems. Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style and not realizing some injected fragment of HTML somewhere relies on it being a certain way. I hope you’re using a monorepo because unlike typescript APIs, those HTML fragments and CSS styles are not type checked.
    - bccdee 10mo ago
      Well yeah, HTMX wouldn't be a good fit for micro-frontends, but I didn't think many people were actually using those. You have to write all your html in accordance with a single stylesheet, but that strikes me as the least of HTMX's impositions.
    - array_key_first 10mo ago
      That's because jquery takes a very global approach to the DOM, which will naturally lead to spaghetti code. Every backend framework, be it dotnet or Symphony or Rails, has a concept of components. It's a non-issue.

by stefan_ 10mo ago

ErroneousBosh 10mo ago

> It's terrible, why would I want my endpoints to return random HTML fragments? What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).

stefan_ 10mo ago
HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.
- ErroneousBosh 10mo ago
  Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.
  - leoedin 10mo ago
    I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment. The only exposure the back-end has to HTML is streaming the static files to the browser. Which can be done in small chunks. If your back-end is rendering HTML with every request, it has to do a lot more work. It has to load HTML templates into memory and insert strings into them.
    - goodpoint 10mo ago
      This is plain false.
    - ErroneousBosh 10mo ago
      Okay, so how do you actually show the stuff to the end user? Just raw structs of data? Or do you turn that back into HTML? Now you've got two sets of templates to cope with... Why would I care about how much effort it is for the server to generate? It's already generating HTML from templates, and it's more-or-less infinitely capable of doing so.
    - bccdee 10mo ago
      > It has to load HTML templates into memory and insert strings into them. In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.
      - stefan_ 10mo ago
        Three levels down and people have entirely forgotten what my post was. My "server" is some anemic ARM core built into real physical hardware with 64M of read-only storage. I don't want it spending its time "hydrating" some DOM, I don't want to bring any of this frontend insanity on there at all. No code hosted on npm shall ever run on that processor or I can't go to sleep in peace. So how do we still get a fancy SPA website? Build it all down to a simple zip bundle, the ARM can serve those static files just fine. The SPA talks to the ARM via a few JSON APIs. Very nice clean boundary.
        listenallyall 10mo ago
        Yes, if your server is a weak, limited processor, you want to keep the demands on it as low and lean as possible, and let the client do the heavy lifting. HTMX is not a good fit for this scenario, just like PostgreSQL is not a good database to embed on your devices. This isn't a controversial idea and nobody would try to sell you on HTMX for your use case.
- wrs 10mo ago
  I don’t get what you’re saying (maybe there’s a typo). With React, generating HTML on the embedded device is exactly what you’re doing — twice (virtual and real DOM).

drcongo 10mo ago

The HTML fragments aren't random.

bottlepalm 10mo ago

Returning HTML sounds like a styling nightmare, if anyone changes the structure, unintended consequences. Plus it’s difficult to reason possible states of the UI with fragments sitting on the server, possibly dynamically built on the server. Very jquery/PHP ish. I had my fun and don’t want to go back.

robinhood 10mo ago
Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.
- bottlepalm 10mo ago
  I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems. Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style and not realizing some injected fragment of HTML somewhere relies on it being a certain way. I hope you’re using a monorepo because unlike typescript APIs, those HTML fragments and CSS styles are not type checked.
  - bccdee 10mo ago
    Well yeah, HTMX wouldn't be a good fit for micro-frontends, but I didn't think many people were actually using those. You have to write all your html in accordance with a single stylesheet, but that strikes me as the least of HTMX's impositions.
  - array_key_first 10mo ago
    That's because jquery takes a very global approach to the DOM, which will naturally lead to spaghetti code. Every backend framework, be it dotnet or Symphony or Rails, has a concept of components. It's a non-issue.