[t-writescode]

You can accomplish the "don't have to reload the page to see my changes" with htmx and it's still "server-side rendering" (or mostly server-side rendering). Legendarily, the fastest website on the internet uses partial page caching to achieve its speed

[hirvi74]

What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.

[t-writescode]

I like that it still feels like html. I think that's it's biggest selling point.

You write:

  <div id="moo" />
  <form hx-put="/foo" hx-swap="outerHTML" hx-target="#moo">
     <input hidden name="a" value="bar" />
     <button name="b" value="thing">Send</button>
  </form>

Compared to (ChatGPT helped me write this one, so maybe it could be shorter, but not that much shorter, I don't think?):

  <div id="moo" />
  <form>
     <input hidden name="a" value="bar" />
     <button name="b" value="thing" onclick="handleSubmit(event)" >Send</button>
  </form>

  <script>
  async function handleSubmit(event) {
    event.preventDefault();
  
    // the form submit stuff
    const form = event.target.form;
    const formData = new FormData(form);

    const submitter = event.target;
    if (submitter && submitter.name) {
      formData.append(submitter.name, submitter.value);
    }

    // hx-put
    const response = await fetch('/foo', {
      method: 'PUT',
      body: formData,
    });

    / hx-swap
    if (response.ok) {
      const html = await response.text();
      // hx-target
      const target = document.getElementById('moo');
      const temp = document.createElement('div');
      temp.innerHTML = html;
      target.replaceWith(temp.firstElementChild);
    }
  }
  </script>

And the former just seems, to me at least, way way *way* easier to read, especially if you're inserting those all over your code.

[hirvi74]

Yeah, the JS could technically be shorter, but your example is functional enough to get the point across.

Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever?

I have successfully gotten this to work in HTMX before. However, I had to rely on the JS API for that is outside the realm of plain HTML attribute-based HTMX. At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example, but I would argue it's actually much more annoying to deal with.

[yawaramin]

> At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example

Not sure exactly what you're talking about w.r.t 'the amount of work one has to do with the HTMX JS API', but I've found that form validation with htmx and a backend server works really well with just a tiny bit of JS and a little care crafting the backend's validation error response: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

[recursivedoubts]

two possible approaches:

1. Do the validation server side and replace the input (or a label next to the input, see https://htmx.org/examples/inline-validation/)

2. Use the HTML 5 Client Side form validation API, which htmx respects:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

[hirvi74]

Well, I never expected to get a reply from the man himself. Thank you for taking the time to respond.

So, I did end up going with #1 with a slight variation.

You also commented on another comment of mine stating:

> if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended

There seems to be some confusion, and I apologize. I extensively used attributes. That wasn't the part of the API I was referring to. Rather, I should have specified that I was heavily relying on a lot of the htmx.on() and html.trigger() methods. My usage of htmx.trigger() was predominately due to something being triggered on page load, but also, it needed to be triggered again if a certain condition was met -- to refetch the html with the new data -- if that makes sense.

I should also preface that I was working on this project about two years ago. It looks like a lot has changed with HTMX since then!

[recursivedoubts]

maybe check out fixi.js:

https://github.com/bigskysoftware/fixi

[hirvi74]

I appreciate the suggestion. Not sure I am a fan of this implementation though. It looks near identical to the HTMX JS API that is already backed into HTMX. Most of the annoyances I dealt with were around conditional logic based on validation.

After enough of the HTMX JS API, I figured, "What is HTMX even buying me at this point?" Even if plain JS is more verbose, that verbosity comes with far less opinions and constraints.

[recursivedoubts]

if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended