Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Root3875060dDefinitely more complicated, at least to set up.
Backend requires more careful planning, building, and handling.
ltlian75560dI'm more or less full stack right now and I definitely find frontend harder.
The backend/api is just returning arrays and jsons, returning "sorry no, you/I fucked up" on error, maybe interpret some complex(ish) query params - but holy butts the frontend.
We can talk about how js suffers from frameworkism, but I often feel like 3/4 of my job centers on handling/preventing invalid input, spending a week making an intuitive ux component which ultimately only returns an integer, then having to redo half of it because - without realizing it - I had made an assumption of how a thing should work that wasn't what the client had in mind.
Still fun though. My only reaction to people looking down on frontend as "the easy bit" is that they haven't worked with it.
AlmondSauce279960dFrontend is a bloody mess because everyone uses something different.
Want to use JS? Great - pick your framework of choice. Angular 1, angular 2+, React, Vue, jQuery.... CSS? Cool! Fancy less, sass, or something else?
But the real kicker comes when people combine the above in terrible ways. I've seen projects that use AngularJS as well as React, but also with JQuery thrown in there because that's the only way the intern knew how to select an element...
I think frontend gets its "easy" reputation because 15 years ago JS was a simple language, there were little to no frameworks to learn and requirements were generally a lot simpler back then. That was before the era of webapps though.
"like 3/4 of my job centers on handling/preventing invalid input"
^ This shit. This is legit half the code I write.
"people looking down on frontend as "the easy bit"
Or the UIs they did were so loaded with Bootstrap / UI libraries that you could tell they were shit for their users
"only way the intern knew how to select"
Lol, 2 ways. With Angular, use ids, and with everything else, document.querySelectorXXX.
"easy" reputation because 15 years ago
Yes. It's no joke anymore, and front-end devs are actually super talented, and way undervalued.
asinglenoob13259dHere’s a question for the people saying they spend their whole lives preventing bad user input, why? Why is that not being handled server side? I mean in MVC it’s literally as simple as dropping a decorator on a view model property and you’re done. Unless it’s people using these new fangled JS backends or something crazy like that.
asinglenoob13259dYou could spend literally the next 100 years trying to prevent bad user input on the front end but at the end of the day the user can just send raw JSON to your server if they really want to enter bad inputs.
ltlian75559d@asinglenoob Oh, I wasn't referring to malicious input. That's a separate issue where you simply abort once you catch it. You don't spend time returning useful errors to someone circumventing your user interface.
I'm thinking in terms of ux design and making it intuitive, and warning before allowing the user to send or returning a pretty, useful error if it's not possible to catch it before it's sent.
Lately I'm making a table that's basically an outline of invoice candidates. It's trivial to assert whether an object can be upgraded to an invoice and get an output of what fields are missing if it's not, but designing the frontend around navigating these candidates, checking their info, guiding the user on what's missing and what they need to fill in to make a valid invoice is an order of magnitude more work than the time I spent on the backend.
You basically validate twice. Once on the client side, and once on the server side. If the client validates it, it's basically so the server doesn't get as much traffic. If the server has to do all the heavy lifting in validation, you have to pay more for your server because a lot of calls your own app is making are not sending valid inputs.
Also, on the client side, sometimes you have to sent and manipulate data across your client-side codebase. There are times in which the user input has to be valid, and of a specific type, or future calls will not work.
Combine these two things together, and you end up with a lot of your time being input validation
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job