My own experience from a time at a SpringBoot/iBATIS/Hibernate etc. shop (so server-side not UI side) is that it's all well and good running on "rocket fuel" as the consultants say, until something goes wrong. Then at some point you need the person who understands HTTP and SQL and other antique stuff to diagnose the problem, even if you can fix it at the abstraction layer.
One of the problems we had one day, was that a particular script "just wasn't working" and it turned out the file was being sent correctly, but with the content-type set to "text/html" by mistake because someone's "clever trick" interfered with SpringBoot's "magic" so the content-type detection wasn't running the way you'd want. Easy to fix, but you need to know what's going on in the first place.
Over time I also developed a feel for code smells of the form `return SomeItemDAO.fetchAll().size()` which runs just fine on the test server with a few thousand items, then you deploy it to prod where there's tens of millions and the database is on a different machine. It turns out SELECT COUNT is a thing!
Assuming anyone cares enough. Alternative approaches include, ignoring the problem, working around it, or changing business requirements so that the feature isn't available anymore.
There are a lot of people in the industry that just throw up their hands at roadblocks they can't solve and say something is not technically possible. These people include "tech leads" or other high-level software roles at companies.
I have known a tech lead, one-self a java developer, who could not compile java code to class/ jar file that could be added to a docker layer in a pipeline.
As a proof occasionally somebody will post something on HN about performance (asking for guidance, showing off a refactor, claiming performance is a critical must, whatever). I show them how to achieve load times of less than 100ms on a OS like GUI with full state restoration and the feedback is always the same. Either they can’t hire anybody who is capable of following that guidance or the juice isn’t worth the squeeze. Nothing in the guidance is challenging. It’s just not framework bullshit.
This is the main constraint when designing some solutions. Oftentimes I know the best path (or that something deemed impossible is completely doable), but it might be arcane knowledge and I would be the only one to know how it would work and be responsible to keep it working.
Bus factor of one strikes this right away, unless there are no alternatives.
Seriously, think about this logically. The compile target of the browser is the DOM. What is it these developers are so deathly afraid of: the DOM. Yes, it is raw emotional fear processed in the amygdala, qualified with poorly formed bullshit excuses. So, what about this induces fear? It’s not the technical challenge, because it’s not that challenging and easily taught to non-developers. I know this from experience. That’s how I know it’s a selection problem.
As a 15 year former JavaScript developer I can see that things are changing in this regard with hiring slowing down, but there remains close to no incentive to be good at any of this. Even if you are good at this and defy all extreme expectations by finding a job that values bleeding edge performance over hiring you won’t be paid any more for the rarity of your talent/experience so why bother?