IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion.
For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise.
The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it).
The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day).
I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)
The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your current UI state to the new UI state (hide this button, disable this input, etc).
Similar idea was used on Oberon System 3 Gadgets toolkit.
Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.
This is markedly different than React, where the framework diffs the desired UI state (which is a pure function of your application state), and the actual UI state. The minimal number of UI operations necessary is then applied to make the latter match the former.
ImGui above works the same way, which makes it very popular for devtools in game development.
The source code of quite a few ones is available around the Net.
Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.