So Many Frameworks use Server Side Form and Javascript Processing?

Several reasons:

• The data has to come from the server in any case
• Not all clients support JS and have it enabled ** Search engines are a prime example of clients which don't generally support JS
• Linking is much easier when you aren't mucking about with #
• Browsers don't have identical DOM and JS implementations

The server processing time involved in either approach is trivial compared to other things that are going on in the backend.

Form validation exists on both ends because even if client side form validation is perfect you still have to deal with requests to your URL that come from a source other than your page (bots, probes, malicious attacks, etc). At minimum your models and/or form handling code need to reject bogus data.

We don't use a plain HTML for the view because users have come to expect more out of their experience than a simple page that posts to another page.

Since the invention of Javascript (and maybe the <form> itself) there's never been a clear consensus on the best way to handle programming forms. There's been too many people doing too many different kinds of web development for any one approach to take hold.

So, when you invent the perfect way to handle forms, be sure to open source your code and share it with the world! ;)

From the way I interpret your question, the biggest reason to me seems to be crawling by the browser. HTML generated dynamically server-side is just plain HTML to the browser, so it's crawled as such. If they were created through DOM manipulation through Javascript the result might not be properly parsed (if parsed at all) by the crawler.

On the extreme end, you could have just a skeleton with javascript and data and the entire page is generated client-side, but that would be much harder on the designer I think than learning the templating language used in whatever framework is being used.