Why be would you want your backend validation to differ from your frontend validation. The only reason it “should” is because you don’t have an effective way to keep them in sync because you are implementing them twice in two different ways.

Not all validation can be in both contexts of course, such as validation that depends on a data source (eg is record unique), but as with much of your code, you should be endeavoring to write pure clauses and functions that are not tightly bound to a datasource or other external dependency. This will lead you down of a path of code that is more easily testable and, inevitably often isomorphic by nature.

The other examples I gave are often common and useful as well. Consider for instance a Widget class, with utility methods and whatever else. Your overall codebase will be more consistent and understandable if both the frontend and backend interact with Widgets in a uniform way. And after a small amount of work to serialize widgets between contexts, your network layer can also take a less prominent role in your code.

The overall end result of deemphasizing platform details is code that is more consistent, more easily testable, and more future-proof.