No. It's not too complex. It's just boring. And you people keep reinventing the wheel and presenting old concepts as "revolutionary" or "innovative". That is why you get looked down upon.

Or you don't understand the needs or the technology because of your stubbornness and ignorance.

That's why I look down upon engineers with your mindset. I won't generalize all backend engineers as you did to frontend though.

I've met many who get it but of course prefer the peacefulness of controlling the environment and the limited state of a server.

I didn't say I look down upon frontend devs. I said that because of the way frontend seems to be chasing trends a lot of people look down on you. Maybe I should have said "That is why you get looked down upon by a lot of people".

Why are you assuming I am a backend dev? In fact why do you even assume I do web dev? You do know that there are many more areas where programming is needed, right?

Do you have the same judgement you invented or would you like to mind read other's opinions and generalize groups of people some more?

How I took that is you just don't want to commit to your own statements, so you speak through these "others"...

And backend isn't just web. I was using a catch-all to call out how, misinformed, ignorant, and offensive your statement was.

The reason you think frontend is more complicated is because of historically terrible terrible decisions made. Frontend is made complex because of the initial idiots developing it.

I didn't make anything up. I just noticed that frontend devs were being looked down upon when talking to some devs and I investigated further. It seems that most frontend devs are just what is usually called "code monkeys" who just fling shit until it works. No real understanding of math, algorithms, architecture and general good engineering principles. Which is also why usually frontend code looks like garbage. I am sure there are exceptions but for the most part frontend stuff doesn't get the best and brightest people working on it. Because it's considered boring and uninteresting. Personally I don't care. Web dev in general seems to be complete and utter trash and I work on things that are on a completely different plane of complexity (as in if things go wrong people die). It's just funny that you still cling on to the idea that frontend is some sort of holy grail of engineering and absolute complexity.

Do you write in assembly?

Very rarely. Hmm, I don't think I wrote assembly in the last few years though. Why?

The only people who look down on frontend or backend engineers are people who don’t understand what it means to be great in either domain, and are too arrogant to take the time to learn and appreciate its nuances.

Every engineer I’ve known who’s “looked down” on frontend or was dismissive of it was not only bad at frontend and didn’t understand what it takes to be good at it, but also a jerk about the perceived depth of their own knowledge.

I don’t think this is a truly irreconcilable stance and I don’t think it’s exclusive to frontend, you run into it up and down the stack.

I think there are two approaches to software development, and a gradient of people transitioning between them:

(1) I’m responsible for this system and I either have to understand this well enough to feel comfortable being directly responsible for it or delegate responsibility through my org structure or vendor contracts.

(2) I don’t understand how any of this works, it’s just a bunch of magical incantations that get me results, and one incantation is interchangeable with another.

Your dumbdumb fake engineer isn’t a fair characterization of (2) but I do believe a lot of tools in a lot of ecosystems are optimized for engineers without the depth of knowledge necessary to operate them under the API contract.

That’s totally fine when that API contract is provided by a responsible party you can delegate responsibility to. The problem comes in when you provide these “simple” API contracts on top of extremely complex internals and hand them to a developer/user who is ultimately responsible for the entire stack, internals and all.

In some cases (2) can offset risk using a “cattle” approach where multiple live versions of the system are kept up, changes happen one at a time, and you can fail over if something goes wrong and throw away the old state. I’ve met engineers who operate K8S clusters this way. They are clearly out of their depth with kubernetes, but they can fail over to a secondary and rebootstrap a bad cluster from scratch to get back to a good state. By keeping things disposable you exclude most (all?) failure modes other than “poison pill” bugs that repeatedly put your system into a bad state.

But, for the most part, these complex open source systems that try to hide complex internals give the illusion of delegating responsibility. You might get pretty far before an incident comes knocking and it’s time to pay the toll.