In web design, everything easy is hard again

> A door knob that's most intuitive and natural for the majority of humans to use.

Ok so let me explain better:

The UX = Human End-users POV (intuition)

Programming syntax = Human Developers (intuition or whatevr)

Tools to deliver (Browser API, CSS) = The domain/s

The way in which we structure work = the things we are building = things that exist in real life.

Websites are mis-leading because many pages appear alike people tend to believe that there's a lot of repetitive components but there really isn't in general.

So inheritance is usually way over used despite the style of programming.

I am not discussing how we use a door knob. I'm arguing about how we build the door knob of different variants in mass production.

> It's not Brainfuck-bad

Brainfuck is not a "bad" language, if it serves it's purpose well then it is good. I think Brainfuck is doing exactly what it intended to do.

There are people who have been using JS for 20 years who think it is terrible. It's because they have never taken time out to learn the language properly. Most JS devs don't

I'm not convinced that you have because you clearly wouldn't be saying x is a poor language. No language that is in high demand today is a poor language.

Nothing is new under the sun, something old becomes something new in a different context in a different time, same thing happens in music and fiction... so what?

> There may be edge cases that the new solutions helps with that the old solution couldn't handle

It's pretty condescending to reduce the work of many smart and passionate programmers down to "a bunch of edge cases". People put real work and thought into these projects based on their professional experiences and it's depressing to me that others can be so cynical that they're unwilling to imagine that maybe there's something they aren't seeing about why so many of their colleagues are excited about what these tools make possible.

> but that begs the question, why didn't we just improve the old tool instead of making a brand new one?

Setting aside the clearly obvious reasons why we don't (and can't, and often aren't welcome to) contribute to existing tools rather rather than roll our own - who is worthy enough to determine which projects deserve eternal tribute and which projects are allowed to even exist? Your question is absurd. Why don't all these hugely popular tools with active open source communities just disappear? Umm, why should they have to? Why don't all the people who have a problem with it disappear back to a world where they can manipulate individual DOM nodes to match their application state with imperative instructions... you know, the present world they live in right now?

> This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field

I'm not understanding the complaint. "Pressure to stay relevant in the field" sounds a lot like "keeping up with advances in the field". I understand you don't agree that they are advances, but a lot of people disagree, including many individuals leading companies and organizations highly regarded for their engineering talent.

> When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point?

If you're tasked with the responsibility of deciding which technologies are the most appropriate choices for a project and you decide to pick "B" because it's popular, rather than "A" because its a tool that you understand and claim is "just as good" as "B", YOU are to blame; by your own logic you're just giving yourself an intentional handicap so you can look cool.

> Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers

Who's to say what 95% of developers need? Some would say 95% of developers don't need javascript at all, so I guess that settles that.

And you're right that most sites don't see traffic numbers to justify exotic AWS setups. I personally think most web businesses grow pretty linearly, so the focus on "overnight" scaling problems is more of a sales tactic than it is reality.

I do think you're underestimating the amount of companies that do need these tools, though. It's not as binary as "insurance broker" and "Facebook". Logistics companies, payment processors, restaurant groups, grocery stores, etc. all have pretty complex backend services and some of these tools are critical to even compete in their industries.

I understand what you're saying, but the bottom line is that "the conforming pressure" is illusory. At the end of the day the engineering team must deliver a product that works to specification and is not difficult to maintain, that is the only real pressure, there is no rational justification for choosing a tool that is less likely to accomplish that goal when a suitable one already exists. If someone is in charge of building a "brochure website" and they select a complicated SPA pipeline with many build steps as the solution then they are objectively doing the wrong thing and that's the end of the story, nothing in that scenario reflects on any aspect of the actual tools.

> You can't pretend that people conform to social pressures.

I don't, but those people are the problem, not the tool.