Absolutely agree. I have never understood why you needed to cram 500Kb of JS down the user’s gullet just to display 10Kb of text. The vast majority of sites have absolutely no need to be responsive, and what little responsiveness would be effective (sorting abilities on large amounts of frequently-accessed paged tabular data) should be sprinkled in on an as-needed basis. Hence the beauty of Vue.
>ideally, actions that do not required a round-trip to the server wouldn’t use one. A good example of this is form validation.
Client-side validation should always be structural-only, to provide fast-fail feedback to the user prior to a full-page round trip. As in, is there a first name present? Does the eMail address make sense? Are there sufficient digits in the phone number for it to be valid?
Plus, input masks - which clearly provide immediate feedback as the user is typing on how complete some content can be - are an excellent way to give real-time feedback to users. For example, in North America you could set up a phone number input mask to be: `___-___-____`, and not only would the underlines be replaced by numbers as users type, but the input would also be limited to only numbers, preventing malformed input! As a final bonus, any non-placeholder part of the mask - like the separator dashes - would not be included with the form submission, allowing you to drop the phone number into an `integer` field in the DB, thereby avoiding the need to use a corruptible `nchar(12)` field.
And once the form is submitted, the server-side validation should include all the client-side validation only top of business rules that check the nature of the data itself. Such as whether the phone number is only integers 10 digits long, or whether the domain of the eMail address - especially if it isn’t a common/known one - resolves to a live MX server.
Absolutely agree. I have never understood why you needed to cram 500Kb of JS down the user’s gullet just to display 10Kb of text. The vast majority of sites have absolutely no need to be responsive, and what little responsiveness would be effective (sorting abilities on large amounts of frequently-accessed paged tabular data) should be sprinkled in on an as-needed basis. Hence the beauty of Vue.
>ideally, actions that do not required a round-trip to the server wouldn’t use one. A good example of this is form validation.
Client-side validation should always be structural-only, to provide fast-fail feedback to the user prior to a full-page round trip. As in, is there a first name present? Does the eMail address make sense? Are there sufficient digits in the phone number for it to be valid?
Plus, input masks - which clearly provide immediate feedback as the user is typing on how complete some content can be - are an excellent way to give real-time feedback to users. For example, in North America you could set up a phone number input mask to be: `___-___-____`, and not only would the underlines be replaced by numbers as users type, but the input would also be limited to only numbers, preventing malformed input! As a final bonus, any non-placeholder part of the mask - like the separator dashes - would not be included with the form submission, allowing you to drop the phone number into an `integer` field in the DB, thereby avoiding the need to use a corruptible `nchar(12)` field.
And once the form is submitted, the server-side validation should include all the client-side validation only top of business rules that check the nature of the data itself. Such as whether the phone number is only integers 10 digits long, or whether the domain of the eMail address - especially if it isn’t a common/known one - resolves to a live MX server.
(2024)