3 ms·

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username leng

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

8organicbits 4y ago
Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example. One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated. Ideally, you'd have a single source of truth that both front-end and back-ends are built from. That's easier if they use the same language, but it's not a requirement. You'll also probably want to deploy new back-end code and front-end code at the same time, so just using JS for both sides doesn't magically fix the synchronization concerns. One idea is to write a spec for your input, then all your input validation can compare the actual input against the spec. Stuff like JSON schema can help here if you want to write your own. Or even older: XML schemas. Both front-end and back-end would use the same spec, so the languages you pick would no longer matter. The typical things you'd want to check (length, allowed characters, regex, options, etc.) should work well as a spec. It's also not the only place this type of duplication is seen: you'll often have input validation checks run both in the server-side code and as database constraint checks. Django solves that issue with models, for example. This can be quite efficient: if I have a <select> in my HTML and I want to add an option, I can add the option to my Django model and the server-side rendered HTML will now have the new option (via Django's select widget). No model synchronization needed. As others mention, you may want to write additional validations for the client-side or for the server-side, as the sorts of things you should validate at either end can be different. Those can be written in whichever language you've chosen as you're only going to write those in one place.
- emodendroket 4y ago
  I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.
La_Beffa 4y ago
A possible solution could be what ASP.NET does where you can just set the validation rules in the backend and you get the client side one too, the magic is done by jQuery unobstrusive validation. Of course something a bit more up to date than jQuery would be ideal but you got the gist. https://learn.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-7.0#required-validation-on-the-client https://learn.microsoft.com/en-us/aspnet/core/mvc/models/val...
pphysch 4y ago
Username length does not "need" to be validated on the client. However, it is nice for UX to enforce it there.
- emodendroket 4y ago
  I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?
  - philderbeast 4y ago
    a requirement that is solved by setting the length on your input field? or have we forgotten that plain hold HTML can validate much of this for us with no JS of any type required?
    - emodendroket 4y ago
      There are limitations to that, as you well know, since you hedged with “much of.” And this is, again, a nitpick around the edges and not really a comment that addresses my main point.
ZephyrBlu 4y ago
You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.
- emodendroket 4y ago
  Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).
  - ZephyrBlu 4y ago
    Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.
    - emodendroket 4y ago
      I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.
      - iainmerrick 4y ago
        Yes, exactly! I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it. And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.
- petepete 4y ago
  > It's poor UX. It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology. Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?
kokanee 4y ago
There are two things that engineers tend to neglect about validation experiences: 1) When you run the validation has a huge impact on UX. A field should not be marked as invalid until a blur event, and after that it should be revalidated on every keystroke. It drives people crazy when we show them a red input with an error message simply because they haven't finished typing their email address yet, or when we continue to show the error after the problem has been fixed because they haven't resubmitted the form yet. 2) Client side validation rules do occasionally diverge from server side validation rules. Requiring a phone number can be A/B tested, for example.
- emodendroket 4y ago
  Even if you’re not A/B testing you’re going to have some validations that only happen server-side because they require access to resources the client doesn’t have, but I don’t see either of these points as arguments against sharing the validators that can be.
  - kokanee 4y ago
    I agree. These points are arguments against the philosophy of HTMX which asserts that you can get everything you need without client-side logic. To be fair, I'm also not a fan of bloated libraries like React and Angular. I think we had it right 15-20 years ago: use the server for everything you can, and use the smallest amount of JS necessary to service your client-side needs.
    - emodendroket 4y ago
      It’s been a while since I did much frontend work but I actually found Angular revelatory. It makes it so easy and it’s really batteries-included.
    - pphysch 4y ago
      > HTMX which asserts that you can get everything you need without client-side logic. That's not true at all. HTMX extends the logical capabilities of HTML, and _hyperscript goes even further.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

8organicbits 4y ago

Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example. One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated. Ideally, you'd have a single source of truth that both front-end and back-ends are built from. That's easier if they use the same language, but it's not a requirement. You'll also probably want to deploy new back-end code and front-end code at the same time, so just using JS for both sides doesn't magically fix the synchronization concerns. One idea is to write a spec for your input, then all your input validation can compare the actual input against the spec. Stuff like JSON schema can help here if you want to write your own. Or even older: XML schemas. Both front-end and back-end would use the same spec, so the languages you pick would no longer matter. The typical things you'd want to check (length, allowed characters, regex, options, etc.) should work well as a spec. It's also not the only place this type of duplication is seen: you'll often have input validation checks run both in the server-side code and as database constraint checks. Django solves that issue with models, for example. This can be quite efficient: if I have a <select> in my HTML and I want to add an option, I can add the option to my Django model and the server-side rendered HTML will now have the new option (via Django's select widget). No model synchronization needed. As others mention, you may want to write additional validations for the client-side or for the server-side, as the sorts of things you should validate at either end can be different. Those can be written in whichever language you've chosen as you're only going to write those in one place.

emodendroket 4y ago
I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.

La_Beffa 4y ago

A possible solution could be what ASP.NET does where you can just set the validation rules in the backend and you get the client side one too, the magic is done by jQuery unobstrusive validation. Of course something a bit more up to date than jQuery would be ideal but you got the gist. https://learn.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-7.0#required-validation-on-the-client https://learn.microsoft.com/en-us/aspnet/core/mvc/models/val...

pphysch 4y ago

Username length does not "need" to be validated on the client. However, it is nice for UX to enforce it there.

emodendroket 4y ago
I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?
- philderbeast 4y ago
  a requirement that is solved by setting the length on your input field? or have we forgotten that plain hold HTML can validate much of this for us with no JS of any type required?
  - emodendroket 4y ago
    There are limitations to that, as you well know, since you hedged with “much of.” And this is, again, a nitpick around the edges and not really a comment that addresses my main point.

ZephyrBlu 4y ago

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.

emodendroket 4y ago
Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).
- ZephyrBlu 4y ago
  Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.
  - emodendroket 4y ago
    I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.
    - iainmerrick 4y ago
      Yes, exactly! I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it. And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.
petepete 4y ago
> It's poor UX. It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology. Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?

kokanee 4y ago

There are two things that engineers tend to neglect about validation experiences: 1) When you run the validation has a huge impact on UX. A field should not be marked as invalid until a blur event, and after that it should be revalidated on every keystroke. It drives people crazy when we show them a red input with an error message simply because they haven't finished typing their email address yet, or when we continue to show the error after the problem has been fixed because they haven't resubmitted the form yet. 2) Client side validation rules do occasionally diverge from server side validation rules. Requiring a phone number can be A/B tested, for example.

emodendroket 4y ago
Even if you’re not A/B testing you’re going to have some validations that only happen server-side because they require access to resources the client doesn’t have, but I don’t see either of these points as arguments against sharing the validators that can be.
- kokanee 4y ago
  I agree. These points are arguments against the philosophy of HTMX which asserts that you can get everything you need without client-side logic. To be fair, I'm also not a fan of bloated libraries like React and Angular. I think we had it right 15-20 years ago: use the server for everything you can, and use the smallest amount of JS necessary to service your client-side needs.
  - emodendroket 4y ago
    It’s been a while since I did much frontend work but I actually found Angular revelatory. It makes it so easy and it’s really batteries-included.
  - pphysch 4y ago
    > HTMX which asserts that you can get everything you need without client-side logic. That's not true at all. HTMX extends the logical capabilities of HTML, and _hyperscript goes even further.