I was thinking this too. Forms never _needed_ Javascript to post. It's always worked this way. Am I missing something?

If I were to guess, it's probably because you learned HTML before JS. Those who learned JS first, or were never exposed fully to HTML, are unlikely to see the simpler solution first, because they're tempted to use JS for everything. An excellent example of the "when all you have is a hammer, everything looks like a nail" principle.

The simpler solution, being that it is what it is, can't do everything that the advanced solution can do. So it's another misuse of the hammer and nail quote. This is a good example of 2 hammers that are optimized for 2 different use cases.

Explains node.js to some degree too. Very glad I didn't enter the scene now with what I see in JS development.

Alternative HTTP methods (only GET and POST are supported in HTML forms).

Also, there is the setting of HTTP headers which requires JavaScript.

I just use a hidden field to handle that.

  <input type="hidden" name="_method" value="PATCH">

That doesn’t actually handle that however (you’re just telling a server that your get/post intends something else).

The server has to support it.

Form validation.

Form validation doesn't need to be done in Javascript. I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea.

Since any sane application revalidates the response on the server anyway, client side validation is just a gimmick, it's not necessary.

It creates a better user experience.

We create a worse user experience by waiting until the form is submitted to inform the user of some silly error.

For some applications, the difference isn't that big, but for many it brings a significant improvement.

Is it possible to create crappy client side validation? E.g. not letting the user temporarily input invalid data while filling out the form, or displaying over-the-top red error indicators everywhere as soon as a single mistake is made, etc... Definitely. But let's not throw the baby out with the bathwater.

The backend should never trust the client, of course. That is a separate goal of the application, however.

Validation on the client is to catch user mistakes, validation on the server is to catch malicious actors.

> I'd argue that it shouldn't ever be done in Javascript, because that means implicitly trusting the client, which is always a bad idea.

It absolutely shouldn't be done in Javascript only.

> client side validation is just a gimmick

Server side validation requires a whole page round trip. The user will have to wait, lose their scroll position... you can't rely on client side validation only, but neither is it a gimmick.

What is ajax

> What is ajax

Server-side validation relying on JavaScript. You still have to wait for the server to respond, and now you need to implement UI to tell the user something is happening in the background. But at least you can start proactively validating before the user actually submits the form, so there's that.

In special cases, maybe. Basic validation (Email looks like email, number contains no text...) is done by the browser automatically if you use semantically correct <input> types: http://diveintohtml5.info/forms.html#validation

Plus dynamic fields, options

CSRF protection, double submits, etc etc etc etc

I always wish I could ship something like that, and it does sometimes start out that way. But it never lasts, not anywhere that cares more about UX than they care about HTML purism.