39

There's a fella I met on here that I helped learn to program. I pushed him towards Java because it's a fantastic language to learn how to code on. Today he asked me about web development stuff, and I dropped a massive bundle of resources to learn everything he needs to be a web dev.

Two things to note here.

1) It's fucking amazing how far this fella has gone learning on his own. I gave him the resources, and he just gave 'er. Absolutely surpassed my expectations of dedication in every respect

2) I never thought I'd say this, but front end development is officially as complex, or more complicated, than back end development. Like holy shit.

All in all, it's a good start to the day, and I've only been awake for 4 hours

Comments
  • 3
    Definitely more complicated, at least to set up.
    Backend requires more careful planning, building, and handling.
  • 7
    Front end development is complicated because it’s a hodgepodge of various questionable technologies. If you look at the state of front end web development it’s kind of a mess. There’s HTML, JavaScript, CSS, and then in addition to that everything now has some massive JS framework layered on top of it. Like back when people were making native desktop apps shit wasn’t so over done. I mean look at how damned long it takes for modern web pages to load, it’s ridiculous. Sometimes I wish we could go back in time and stop the current direction the web has taken and find a better approach to writing web front ends that isn’t a hodgepodge of frameworks and several languages all heaped into a steaming pile of non-performant junk.
  • 2
    I'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.
  • 0
    Frontend 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.
  • 2
    @ltlian
    "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

    @AlmondSauce
    "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.
  • 0
    Here’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.
  • 0
    You 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.
  • 1
    @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.
  • 2
    @asinglenoob
    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
  • 0
    @jschmold @ltlian There are a lot of reasons "never trust the client" is the first rule of development. 😋
Your Job Suck?
Get a Better Job
Add Comment