3 ms·

> you just made it easier to reply to Ah, makes sense. Thanks! Well, the implication is not wrong. If you validate only during testing, you never validate som

by jraph 3y ago

> you just made it easier to reply to Ah, makes sense. Thanks! Well, the implication is not wrong. If you validate only during testing, you never validate some inputs, the ones that matter: user input. I now see what you mean by hot path, I was imagining something like validating asynchronously, later, when not serving a request for instance.

Dylan16807 3y ago
That all depends on context. If users are submitting data then you don't have access to the producers. I think user data is a good objection, and other people brought that up immediately, I just think it's a different objection than the idea of "if you never check, how will you know?".
- jraph 3y ago
  Fair enough, though it seemed disingenuous of OP to question the optimization of a hugely common process and say "just fix your code" when it's not applicable to a vast (majority?) number of (obvious?) cases. It's not like a huge part of today's computer software was not currently running on servers needing to check user input, including the very website we are commenting on. Browsers themselves need to do it too because they can't blindly trust what the server sends them. It seems like it almost takes effort to ignore those cases. To the point people commenting here even forget that there are other things than the web. If OP wanted to share with us the idea of moving validation to another step in the process, giving a case where it would be applicable, that would have been fine but why question an optimization in the first place? Why not both? It just feels like they are rejecting stuff for the sake of rejecting stuff and I assume this is the reason they got downvoted. UTF-8 validation is something that happens constantly. And even if it's was not, this optimization is probably an interesting technical feat, and we are in a Show HN post too, rejecting stuff like this is just not going to fly on HN. You can question things but you need to be insightful and nice. You make good points but OP didn't make them. Anyways.

by jraph 3y ago

Dylan16807 3y ago

That all depends on context. If users are submitting data then you don't have access to the producers. I think user data is a good objection, and other people brought that up immediately, I just think it's a different objection than the idea of "if you never check, how will you know?".

jraph 3y ago
Fair enough, though it seemed disingenuous of OP to question the optimization of a hugely common process and say "just fix your code" when it's not applicable to a vast (majority?) number of (obvious?) cases. It's not like a huge part of today's computer software was not currently running on servers needing to check user input, including the very website we are commenting on. Browsers themselves need to do it too because they can't blindly trust what the server sends them. It seems like it almost takes effort to ignore those cases. To the point people commenting here even forget that there are other things than the web. If OP wanted to share with us the idea of moving validation to another step in the process, giving a case where it would be applicable, that would have been fine but why question an optimization in the first place? Why not both? It just feels like they are rejecting stuff for the sake of rejecting stuff and I assume this is the reason they got downvoted. UTF-8 validation is something that happens constantly. And even if it's was not, this optimization is probably an interesting technical feat, and we are in a Show HN post too, rejecting stuff like this is just not going to fly on HN. You can question things but you need to be insightful and nice. You make good points but OP didn't make them. Anyways.