I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.
Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why.
Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
I think most of us here would find complexity more interesting.
Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
Breaks it down into simple pieces and explains with clear diagrams.
Thankfully with modern browsers nowadays you can open up their dev tools and use them as a 'scratchpad' to play about with CSS.
Tables require two (sometimes more) separate reflows. Minor changes in one cell can potentially force the entire table (and all its contents) to re-render. I also don't miss the days of slicing up images into tables for the performance and load-time gains either.
I always think the backend versus front end statements are hilarious when cast to other activites. They always carry a tone of derision while completely missing the point that they are different problem spaces and skill sets.
You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks).
Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout().
Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(
The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated.
I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up.
Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack.
I would not dread doing frontend development, if allowed to do things correctly.
And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.
I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal...
Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."