Originally posted by missingno:
I would differentiate between "using JS" and "relying on JS". You should never rely on JS, but you might use it for some parts. For example, if you have to sort an array to display it in your frontend, I wouldn't mind if the client manipulates the result as that only affects his side. But if you store the array back on the server side and "rely" on the data in it, I would have to validate anyways. So in this case, it doesn't make sense to do the sorting on the client side, but rather do everything on the server side and only send the results (which the client may manipulate, but I don't care as the server is still consistent).
Amazing how you miss the point altogether.
You are still in the era of using _area- -/area_ tags:
The user clicks on several check/radio buttons on the form, and types in data in input fields.
The user hits submit button.
The server validates the data.
The server processes the data and sends a new modified image-area, along with the entire page, most of which has nothing to to with this image-area.
--repeat subsection A --several times-- (overworking an already overloaded server) until the user is satisfied with the state of the image.
Now the user clicks on the image-area (it is a color picker).
And we still haven't even mentioned that somehow this process has to keep track of WHICH color-selection-input is getting filled. Remember, we cannot rely on js!
Now the user does all this over and over again, waiting patiently for the server all along..... In fact, every "live" action like this needed must be sent to the server for processing.
After half-an-hour of back-and-forth data transfer, the user finally has a complex web-form filled out (with many fields being being the selected colors mentioned above). The form is dynamic to properly represent all the needed data, so every time the form needs new fields added or fields removed, a special submit button must be pressed by the user, and the server will add or remove the proper (new or old) fields, and send the page back to the server, keeping track of every POSTed variable to properly set the form inputs to the previous user-selections.
The user finally submits the fully completed form with another separate submit button (the form has 100 or so throughout that do various different things - a real swamp of an _application_ if you can really call it that)
The server validates and processes the data, refills the form with the POSTed data, and sends a new web page including a new graphical-image (besides the color-picker image mentioned above) developed from the user-sent data.
The entire process repeats until the user is finished, an hour later.
Any time an __app__ needs to do some work, the server should be minimally involved, if at all.