In my opinion it is the opposite. While modern front-end may be much more complex than back-end if you take the wrong approach towards it, most beginners tend to gravitate towards front-end. This is at least in part due to the greater volume of (sometimes low-quality) courses on basic front-end, which sometimes results in beginners knowing React and JSX but not CSS or JavaScript. But I also think it is because it is much easier to get started with front-end than back-end.

I may be biased about beginners’ preferences.

But the complexity of UI is not a matter of opinion or approach - it is a simple fact of having a far more complex state machine in simplest desktop app than in half of hi loaded services in the world (which are stateless, i.e. not having a state at all).

Frameworks and libraries help alleviate the pain and take care of low level dirty work, but they can’t remove the fundamental source of complexity.

The backend of a high traffic web application (say 5k requests per minute) will have many highly technical problems that require deep understanding of databases, transactions, scaling, networking, and knowledge of CS fundamentals to solve problems in those areas.

The frontend of a high traffic web application will perform the exact same as if that frontend only had 1 user or 5000 at the same time. Any performance problems in front-end are self-inflicted, likely from over-complicated, bloated frameworks and a lot of resume driven development - it can happen in backend too but count the number of frameworks for JS vs Ruby or Python.

Now in my mind, I don't include UX design as part of a frontend developer role and really that has no bearing on actual code, its more about human computer interaction and psychology than what software is pumping out HTML and CSS.

> The backend of a high traffic web application (say 5k requests per minute) will have many highly technical problems that require deep understanding of databases, transactions, scaling, networking, and knowledge of CS fundamentals to solve problems in those areas.

i've worked on services with 1-2M requests per minute - most of them were stateless, and usually are (in a "typical" web company like big e-commerce apps, twitter, etc.)

This doesn't mean they are easy to implement and operate, but they lack one huge source of complexity (in a mathematical sense, i. e. entropy) - the state.

This piece is usually delegated to a database/middleware level and is spread over multiple more or less independent services dealing each with its own tiny slice of state.

On UI (i.e. app with few screens, buttons and meaningful interactions between them - not a dumb statically generated blog) the complexity of state grows rapidly and there is no magic DB to shove it into.

Because the state machine is the core of the app work - user interaction is literally a walking through transitions of state machine.