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.