4 ms·

HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler appl

HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler applications.

verdverm 2y ago
I haven't tried HTMX, can it fetch and load html fragments into an existing dom?
- dlisboa 2y ago
  That's pretty much all it does. It reacts to an event, fetches from an URL, swaps the result from that URL in some part of the DOM.
  - verdverm 2y ago
    Then does the server handling the requests needs to produce html fragments? If I request a page, how does it know to only serve / fetch / render the main content vs the full page? --- It seems like a lot of would be logic a real language has been moved to DSL and strings, i.e. https://htmx.org/docs/#swap-options https://htmx.org/docs/#swap-options `hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'"` Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems
    - dlisboa 2y ago
      Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g. just the partial of the "Todo" list in your "Todo App" homepage). You need some backend logic to handle that but still much less than a full blown JSON API would have. They also have extensions that can diff and merge the DOM so even a full page load would replace just what changed, this way your backend is pretty much unaffected (you just end up serving more MBs). There are other libs in this space by the way, like Unpoly and Hotwire, HTMX just got more mindshare. > Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems I absolutely agree. I had a comment thread with HTMX's creator about this, I feel like it's a bad idea to shove logic into that. He also created Hyperscript (https://hyperscript.org https://hyperscript.org) so it's something he doesn't think is an issue. In general I think it's pretty easy to rein that in. Just use HTMX to do most of the plumbing it's strong at (react, fetch, swap) and keep the logic server-side. In my experience that covers the vast majority of web apps. If I absolutely need more client-side logic I'd reach for a little JS code or create a Web Component.
      - verdverm 2y ago
        CEL (Common Expression Language) has gained the mindshare in the devops / Yaml world, though typically just for the expression evaluation in the context of another system's data https://cel.dev/ https://cel.dev/
robertoandred 2y ago
Why switch to something new and complicated like htmx?

HTMX + React style server rendered components would solve 80% of the use cases for a modern SPA. Keep going! This is a breath of fresh air for many simpler applications.

verdverm 2y ago

I haven't tried HTMX, can it fetch and load html fragments into an existing dom?

dlisboa 2y ago
That's pretty much all it does. It reacts to an event, fetches from an URL, swaps the result from that URL in some part of the DOM.
- verdverm 2y ago
  Then does the server handling the requests needs to produce html fragments? If I request a page, how does it know to only serve / fetch / render the main content vs the full page? --- It seems like a lot of would be logic a real language has been moved to DSL and strings, i.e. https://htmx.org/docs/#swap-options https://htmx.org/docs/#swap-options `hx-on:htmx:config-request="event.detail.parameters.example = 'Hello Scripting!'"` Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems
  - dlisboa 2y ago
    Yes, the idea is to send HTML on the wire. HTMX sends some headers that help you identify the context, this way you can render just a portion of the HTML (e.g. just the partial of the "Todo" list in your "Todo App" homepage). You need some backend logic to handle that but still much less than a full blown JSON API would have. They also have extensions that can diff and merge the DOM so even a full page load would replace just what changed, this way your backend is pretty much unaffected (you just end up serving more MBs). There are other libs in this space by the way, like Unpoly and Hotwire, HTMX just got more mindshare. > Not a fan of this fad of moving programming to embedded strings, also seen in lots of Yaml based systems I absolutely agree. I had a comment thread with HTMX's creator about this, I feel like it's a bad idea to shove logic into that. He also created Hyperscript (https://hyperscript.org https://hyperscript.org) so it's something he doesn't think is an issue. In general I think it's pretty easy to rein that in. Just use HTMX to do most of the plumbing it's strong at (react, fetch, swap) and keep the logic server-side. In my experience that covers the vast majority of web apps. If I absolutely need more client-side logic I'd reach for a little JS code or create a Web Component.
    - verdverm 2y ago
      CEL (Common Expression Language) has gained the mindshare in the devops / Yaml world, though typically just for the expression evaluation in the context of another system's data https://cel.dev/ https://cel.dev/

robertoandred 2y ago

Why switch to something new and complicated like htmx?