Non-Javascript Browsers – Should Websites Support Them?

You do need them as the client can decide to allow javascript in their browsers. You also should consider those people who want to break your software. There are plenty of tools out there that can manufacture posts and submit them to your website without having used your front end.

Client side validation is nice for the user, but the server should never ever trust data that is sent to it.

--Update--

If I'm reading your edit properly, it sounds like the OnServerValidates are duplicating validation functionality that is already present on the server. Since that's the case, then you shouldn't need the OnServerValidates.

Furthermore, you are correct that if a user manufactures a post to your service, it will not trigger the OnServerValidates so you are better off keeping that type of validation where you have it currently on the server.

Use a mvw (model/view/whatever) pattern

• model: "pure" javascript library modelling abstract concepts. This part usually contains objects & methods names related to the application domain (car business -> car objects / insurance contracts) and the data access logic.
• view: a custom language describing how your UI look like. Preferably, the language should be close to HTML.
• something to make both part communicate without having one depend too much on the other. A change in the model data must result in a change in the corresponding elements of the view (model -> view). A mouse click mouse result in a method call somewhere in the model (view -> model).

With those concepts, you can choose different stacks

• You can use a big framework such as angular. The views are html dom template. The model is divided between controllers & services.
• you can use backbone (~model) + jquery (~view)
• you can use react.js

... the list goes on. The number of tools available is actually pretty scary. Check http://todomvc.com/ for a nice list of examples.

Example solution with angular

In angular, the connection between the model & the view is performed with a viewmodel & dual way data binding. A view model is a javascript object. Both the view & the model can read & write to this object, and react to changes.

in your view, you write the HTML:

<TABLE class="list_grey" style="float: left; margin-left: 20px;" ng-hide="hideAll">
<TR ng-repeat="row in rows">
    <td ng-repeat="val in row" ng-class="{selected : val.sel}"> {{ val.label }} </td>
</TR>
</TABLE>

in your controller, you only deal with javascript values:

$scope.rows = [
    [{label : "foo"}, {label : "bar"}],
    [{label : "foo2"}, {label : "bar2", sel : true}]
]

$scope.hideAll = false;

ng-repeat allows you to display a list of items. ng-class & ng-hide are used to control the class & visibility of the elements.

Closing words

Using other frameworks, the resulting organization may vary, but the essential separation still exists. In react.js, the data binding is unidirectional, which implies different construct. The mvw framework usually deals with the communication between the components, so you don't have to use jquery at all.

This is a good thing if your project isn't trivial. Managing a complex app with only jquery can lead to a mess of callback interactions which may become hard to maintain.

Using a full mvw framework such as angular or ember requires some learning. Some other libraries have a smaller scope such as react.js & knockout.js.

Of course you don't have to start learning one of these tools right now. The important thing is to achieve the separation between the view & the model. You can use jquery to write functions which will edit the dom according to observation made on a pure javascript library.

You can also use jquery to write the (view -> model) callbacks. (model -> view) can be written using publisher/observer. This part should be as small as possible, and be the only thing connecting the model and the views.