If your web form is more complex than a paper form, maybe rethink the former? I can not think of a form that can be implemented easily in react, but is difficult in Htmx other than wishing to plug in a React-like global application state and having the job 90% done as libraries.

I just looked at this iPhone alarm clock on Gum Road, which I also read about on HN. The page describing the clock is janky. Slowly scroll down the page (with a track pad) and it will jump up and down erratically as you get past the "Add to Cart" button. Hover your mouse in one vertical position on the page and it will turn the header on and off over and over again.

https://fatiharslan.gumroad.com/l/dieter-rams-inspired-vinta...

Maybe I'm a Luddite but I just get the feeling that we've gone very wrong in our over-engineering.

It looks like the sticky header with "Add to cart" disappears when the large "add to cart" button scrolls into view, and reappears when that disappears.

Yes. But you do it once at submission, not once per page.

What's the difference?

You can split the validation in multiple functions/modules which you can then use both at submission or per step/page.

Also, it seems you're implying having two validation systems (on the client and server) is actually good?

Yes?

You want to validate on the client side because it reduces latency and improves responsiveness.

You want to validate on the server side because you cannot trust the fucking client.

The point I'm contesting is that it's more difficult to validate on the server using HTMX.

And I'm not saying you should be only validating on submit when using HTMX.

Client exclusive validation is quite limited. Very often you need a trip to the server anyway so I don't buy the latency argument.

Plus in most cases showing error messages too fast is terrible UX. The only exception I can think of is when checking the validity of a password.

> Plus in most cases showing error messages too fast is terrible UX.

The solution to that problem is to debounce or throttle your error messages. That allows you to report validation issues to the user quickly, but not overwhelmingly fast, before sending a network request potentially across the Earth and back.

Showing error messages on the client side is not too fast or bad UX. Let's say someone entered an invalid credit card. Or an invalid email. Why even let that touch the backend?

Note that frontend forms libraries allow a lot of choice over when to show error messages.

Validating in multiple places doesn't mean 2x the code. You can validate on both the client and the server using the same code. One of the charms of server-side JS.

Those charms can turn tiresome rather quickly once you discover those server-side JS libraries you're popping like candies are adding bloat and security vulnerabilities once they're shipped to the client side.

Yes, in some cases when you don't need a trip to the server. But you're also bloating the client for no great benefit.