6 ms·

This is a great project, and reminds me a lot of where folks saw hypertext going many years ago. I have read a little of the website and picked through many of

This is a great project, and reminds me a lot of where folks saw hypertext going many years ago. I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content? The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.

recursivedoubts 3y ago
we do have a client-side template extension: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/ however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables) for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it it does, however, emit a large number of events that you can hook into to extend things: https://htmx.org/reference/#events https://htmx.org/reference/#events And it plays well w/ scripting solutions like Alpine.js or, our our own scripting solution, _hyperscript: https://hyperscript.org https://hyperscript.org
- lcnPylGDnU4H9OF 3y ago
  Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.
- pragma_x 3y ago
  Thanks for the thoughtful reply, and the thoughtful architecture.
the_gipsy 3y ago
Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.
- intrasight 3y ago
  This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?
  - abrahms 3y ago
    Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).
    - intrasight 3y ago
      > Mobile phones have less powerful CPUs True - but not by much > Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller > where you already have it loaded into memory anyway Likely not true if implementation uses streaming semantics
      - nchmy 3y ago
        > true - but not by much. False. https://infrequently.org/2022/12/performance-baseline-2023/ https://infrequently.org/2022/12/performance-baseline-2023/
        aatd86 3y ago
        I always see these claims but isn't network the more limiting factor? Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet? Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?

recursivedoubts 3y ago

we do have a client-side template extension: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/ however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables) for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it it does, however, emit a large number of events that you can hook into to extend things: https://htmx.org/reference/#events https://htmx.org/reference/#events And it plays well w/ scripting solutions like Alpine.js or, our our own scripting solution, _hyperscript: https://hyperscript.org https://hyperscript.org

lcnPylGDnU4H9OF 3y ago
Another benefit of using HTML is ease of progressive enhancement. If the default behavior of the server is to render a full HTML page, anyone hitting that URL directly will get the full HTML from the server with no additional back-end work. Additionally, if JS is disabled in the browser, links still work as traditional links.
pragma_x 3y ago
Thanks for the thoughtful reply, and the thoughtful architecture.

the_gipsy 3y ago

Generating some HTML instead of JSON isn't that much data/CPU. But doing all that in the browser might have a big impact on UX performance-wise.

intrasight 3y ago
This doesn't make sense. Can you elaborate? If it's not much work for the server, why would it be work for the browser?
- abrahms 3y ago
  Mobile phones have less powerful CPUs. Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server (where you already have it loaded into memory anyway).
  - intrasight 3y ago
    > Mobile phones have less powerful CPUs True - but not by much > Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller > where you already have it loaded into memory anyway Likely not true if implementation uses streaming semantics
    - nchmy 3y ago
      > true - but not by much. False. https://infrequently.org/2022/12/performance-baseline-2023/ https://infrequently.org/2022/12/performance-baseline-2023/
      - aatd86 3y ago
        I always see these claims but isn't network the more limiting factor? Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet? Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?