Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@retoor I can modify html of any page though. So I guess enforcing on web page isn't really protection anyway.
-
Javascript should be used on the front-end as progressive enhancement. Its immediate feedback in form validation is valuable to the user experience, and worthless security-wise, which is the opposite on the server. Anyone can sniff the API endpoints via the browser network tab and spoof the requests without going through the HTML/JS validation.
Regarding fuck users with js disabled I disagree in part with OP: if your solution is content-driven the basic display should work without needing JS (eg news site, blog). I never understood the craze about building your own blog fully with client-side React -
@BordedDev svelte can suck my reactive dick real hard until i cum some little components all around your slot.
-
@antigermanist Let me know when you come up with something original ;P (PS svelte is more reactive than react)
-
@Tounai I remember using a framework for php that divided out the model view in a comprehensive way. Codeigniter? Its been a while.
-
@BordedDev can svelte do jsx?
-
To me, that‘s just another hot take to gain people‘s attention. It‘s the same shit times and times again, some dude posts something trying to gaslight people into thinking they can‘t code, only to plug their medium article, n+1th js framework, github repo or whatever. Today I’m making you switch all to SSR, tomorrow you totally need another backend language cause omg it’s 2025 and you’re STILL using P# on BozoLite?! and next week my new super lightweight framework will move all you problems to clientland.
Basic principle of social media and women‘s magazines. -
@Demolishun waiting for NextIgniter to come out and make me rewrite my whole projects.
-
@tosensei of course. Any dev worth their salt knows not to trust whatever comes from the frontend. The server SHOULD always validate data first before doing anything with it.
Frontend form validation is simply UX centric in my opinion. It's not for security whatsover, it's just there to save the user's time by avoiding unnecessary validation roundtrips. -
@null-pointer-ex not just in your opinion. that's just how it is.
and the thing is: if you're alread implementing it in the backend, why double your work by implementing it again in the frontend?
after all, you could just be smart about it and asynchronously check the form. you don't need to reload the whole page. and i doubt the user will notice if the info that "dick" is too short a password comes after 0 oder 100 ms -
@possum what's your problem with bozolite? it's a valid technology
-
@tosensei I wouldn't call front end validation + back end validation a silly double work. Back end validation is always needed because users can always modify the request and send some horrible shit to us. It even can be done without leaving the browser. But validating it on front end beforehand is good too, to improve performance for our normal/good behaving users.
-
@antigermanist svelte can do jsx cuz it just plugging in a preprocessor in webpack
I made svelte do pugjs once but honestly it's just like being nitpicky. svelte makes html fine to use. though I still do think html should just all convert to pugjs natively because the syntax is just nicer -
@tosensei lol you sound so much like a down's person yelling really loudly about their tightly held opinion lmao
-
@tosensei I do notice, and it pisses me off every time I click save/register and the page doesn't respond only to come back 3 seconds later going wahhhh! And also clearing the password field because I dared to use a space somewhere it didn't like.
-
@BordedDev well, i'm talking about implementing it in a non-terrible way. 3 seconds is too much. but 200ms - you wouldn't care.
@jestdotty lol you sound like an overly entitled karen (pardon the redundancy) with more mental issues than there are days in a 100-year-calendar -
@daniel-wu the problem about doing it twice instead of doing it once and reusing it: there WILL be discrepancies.
just last year i've inherited a project where the frontend would allow passwords that the backend declined, and vica-versa.
with the additional WTF-bonus of the login-form having a password-pattern validation that didn't match up with the signup-password-pattern.
keeping it in one place completely prevents this kind of problem. -
@tosensei It's not only about implementation, the net isn't always superfast. I have had to deal with forms that work that way literary not processing because it timed out because of a temporary internet cut. With either the form getting stuck in processing if it's “enhanced” or just causing the page redirect to fail. And yes, 200ms would also annoy me — I'd probably be 2 or 3 fields further if that was “real-time” validation, but the screen jitter, the scroll resetting, having to find which field it doesn't like is even more annoying.
Also “terrible” advice but use a node.js based full-stack library (e.g. SvelteKit or next.js), that way you can use zed/yup and use the exact same validation rules on both the frontend and backend -
@BordedDev "but the screen jitter, the scroll resetting, having to find which field it doesn't like is even more annoying."
that's just a problem of "terrible and terribly outdated UX". -
@tosensei No, that's the problem of doing validation on “submit” unless you have an endpoint you call on every keystroke/click you are not going to avoid it:
If I click submit, and it forcibly scrolls to the field, that is jitter.
If it doesn't need to scroll but does focus, I don't know, you have moved my focus.
If there are multiple errors, I now need to search which ones are wrong.
All of these “quit”/frustration moments can be avoided by “just” doing “real-time” validation — normally only possible efficiently in the browser.
If you have an example of this being well implemented, I'm willing to change my mind, but I have never come across it. -
@BordedDev "doing “real-time” validation — normally only possible efficiently in the browser." - that's where you are wrong.
proof:
implement your real-time validation with JS to your hearts content, but in your method `PerformTheActualValidationCheck`, you simply query the backend. -
@tosensei Ok do that in under 20ms, unless you mean, quick and dirty in the browser but do the full check on the backend as well, in which case I 90% support it
I would also say wasting the users' bandwidth isn't efficient, but we're talking most likely less than 1kb right now -
@tosensei If you're generating an OpenAPI doc btw you should™️be able to use that for the validation as well, assuming it can express your requirements + something like https://github.com/hey-api/...
Just to clarify as well, this is something I'd only realistically care about during polish for a public-facing system, not for internal enterprise software. Since in that environment it's all about reducing friction with the client/customer -
@BordedDev we're talking about "validating single form fields" - the total payload of this is significantly less than the HTTP overhead. bandwidth is of no significant concern here, unless you do it very wrongly.
-
@tosensei “we're talking about "validating single form fields"” we are?
The HTTP payload makes it worse (if you're going to make the backend do all the work, use a websocket).
Also, with “here” I assume you mean a first world country? Last I heard, there are still places in Germany with connections at the speed of dial-up, with no possibility of getting anything faster.
BTW those devs on those old projects should probably be taken out back. I'd take the “server does all the validation” approach you're mentioning over that any day.
If you're working with a decent number of forms, it's evidently worth investing/developing in a system to keep them in-sync if you're one-for-one matching the requests. Generally, that's not how I set up my form <-> backend combination, since I try to make sure the form is as easy/flat to use for the user as possible. Meaning I'll have to create separate data structures that map to the backend anyway.
What only relying on JavaScript for HTML form input validation looks like
Found something true as 1 == 1
Am I going crazy or is the web dev community on some otherworldly drug?
Now "server-side"-whatever is the coolest thing ever?
To the point where client side validation is not recommended anymore and actively discouraged? Are you kidding me? So, you mean to say after filling a long form with millions of fields, the page will RELOAD when I press submit and after waiting an eternity for your shitty server to respond then and only then will I know what fields are invalid?
GTFO with that bullshit.
How in the world is that good UX/UI?
I've always had this theory that we humans are the dumbest species to ever walk this earth. I mean, serisouly, how is this even a thing?
Imagine if a mobile app had to restart to tell you that your email is invalid in a simple form.
But.. but... but... what if the client has disabled javascript? Then fuck them! Who the fuck cares? What's next? Some dumb user is still using Android 2.1 Eclair and we should make our app support them? Fuck no! Fuck them, they should update.
Newsflash, if Javascript is disabled, then pretty much everything will be broken anyway.
Form validation should be instantenous. This isn't rocket science.
It should happen as the user types so they can see what's valid/invalid in real-time.
This does require effort and consideration, something many devs lack apparently.
This is just ridiculous.
rant
web
javascript
ts
js
webdev