[Dalewyn]

>Also, JS runs client-side which is better than relying on code that runs serverside, as a rule.

This is not true, server-side code is a fixed, known environment so it is strictly better for any critical code and especially anything to do with security authentications.

[deely3]

Parent comment probably mean "better/clearer for user", while you arguing is what " better for provider".

[Dalewyn]

It's also better for the user.

Do you really want your super important and critical stuff to be handled by code that can be examined and modified on the fly with no damns given with the server completely unaware?

Not to mention server-side code by its nature doesn't execute client-side, which means less end user system resources used and thus less electricity consumed by and billed to the end user.

[sanderjd]

> Do you really want your super important and critical stuff to be handled by code that can be examined and modified on the fly with no damns given with the server completely unaware?

Is this supposed to be an obvious "no"? To me it's a pretty resounding yes.

Personally, I'd like servers to do a good job of returning well-structured data quickly, and to be able to manipulate that however I want on the client side.

[MrJohz]

Anything that is "super important and critical" will need to be validated on the server no matter what. But by pre-validating things in the browser, the user can have a more intuitive, seamless experience. Is the username you're typing already taken? No need to press the submit button, then scroll around trying to find the correct error message, we can give you feedback while you type.

You are right that there are tradeoffs, and I agree that client resource usage is under-analyzed, but sensible use of client-side code can make things like forms, visualisations, tables, etc much easier to use.

[onion2k]

server-side code is a fixed, known environment

At least until someone changes it.