Protip: I usually add a hidden input field to my forms. As it is hidden a normal user should not be able to fill it out, only a bot will. So if the hidden input isn't empty, I can disregard it as spam, it works wonders.
I do the opposite: a hidden field that is filled automatically by javascript. Yes, that means you can't submit without JS. That's a tradeoff I was ready to make. I'm actually surprised it still works as well as it does.
For many sites, turning off JS is not an option. IMO, it's wasteful to ignore all that compute power in the browser. It's better to run code in thousands of browsers than do it all on the server.
The user already is. The casual user's system is idling with all sorts of nonsense. Adding some light processing doesn't harm. I'm thinking 100-500ms per page. You don't render the page for the user neither, do you?
For heavier use cases (e.g. image processing), the user should be willing to spend some CPU power. It doesn't make sense to send an image to a server, put it in a queue, wait for an image processing worker to run it, and send back the result. It's simpler and more sensible to run that process client-side, if feasible. E.g. LLMs are too big for that, but many other tasks can.
Some "light processing" like 10 seconds of instantiating <js framework of the day> crap that gives me nausea while it redraws infinitely and boxes move around on the page?
Even the mobile oriented samey SAAS sites that have you scroll through 20 screens to read 5 lines sound better...
Edit: Btw, 100-500 ms on what? The latest Intel 500 W space heater? And tested only in Chrome because it's too expensive to notice that it's not very fast or responsive on other browsers?
Edit 2: Not to be misunderstood. If you're doing the computation for me, go ahead. If you're doing the computation because your framework has 100000% overhead, no thanks.