[timw4mail]

How do forms require Javascript in your view?

My experience is that most of the Javascript used for forms is for fancy custom controls (where a standard one would be fine), weird editing flows (like click to edit), or other functionality which isn't actually needed.

That's not to say that JS with forms is evil. HTML validation is better than nothing, but complex data requirements may require custom validation logic in JS as a convenience to the user.

[kaishiro]

JavaScript is a requirement on most forms due to either designer or client expectation. They want styled, custom client side validation. They want a visual loading state while the form is being fetch'd to the server/service. They want a nice success message to display inline once the submission is complete. Rarely is it custom controls or weird editing flows in my experience - it's much simpler than that.

And we do it because they're paying the bills - there are more important hills to die on.

[tomlagier]

Validation, datepickers, multi-select, other complex controls, dynamic forms (think "add row"), accessibility. You can definitely get away with simple forms in pure HTML, but again it puts a hard limit on the complexity you can support.

[majewsky]

Examples where some JS has its place for forms:

1. The browser already gives you <input type="number"> or <input type="date">, but you may also need <input type="credit-card-number"> or <input type="expiration-date">. For credit card numbers (or bank account numbers) specifically, you want the input field to break it up into groups of 4 digits similar to how it's printed on the card, to make it easier for the user to double-check their input.

2. Suppose you're in the checkout workflow of a webshop. While choosing a shipping method and destination, I want to see the final price update to reflect my selection immediately. I don't want to flip back and forth between selecting a shipping method and seeing the actual cost on the final confirmation screen.