As is the case with much of the front end tooling, once you peel back the curtain, it isn't too terribly complicated. The biggest issue is following the data transformations through the code base because JS being a dynamic language, a lot of magical transformations can happen, but thankfully TS and other compile-to-js languages are helping a lot on that front.
Meanwhile, trying to peel back the layers of k8s, the authors of which seemingly hellbent on bringing Java-esque levels of over-engineered, over-architectured coding styles to a language which ironically supports simplicity and readability over all is a brain melting exercise. I understand Paxos and SAML better than most modern backend cloud tooling codebases. Then like a parent commentor mentioned, throw in AWS services soup in the mix, call services that have a mixture of async and sync calls with a nice mixture of some responses being consistent, some eventually consistent, some probably consistent, throw some observability, and control and data planes and you got a nice recipe for a big bowl of spaghetti you will truly never understand.
But everyone demands these things now, so what are you going to do.
I am not sure if anyone has mentioned it already but in my experience, oftentimes it is not the particular 'complexity' of what is revealed 'once you peel back the curtain', but rather the sheer number of different curtains that must peeled in order to build a 'modern' solution.
My gut impression is also that the challenges are more about aggregate-quirks across the many tools that comprise a solution than it is due to the aggregate-complexity.
For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else.
It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.
And yes, I was wrong, rails has been around longer than that, it was just a guess.
The reason I've been teaching it myself, despite Elixir being a young, niche language is that I believe it's an ideal choice for a solo-founder or small team trying to build an ambitious web app. It's a tool I personally want to have at my disposal.
Discord is a great model: start with a simple Phoenix app, ship way faster than the competition, build out more sophisticated infrastructure with scale, and then finally rewrite core loops as NIFs (natively invoked functions) that are implemented in Rust. They were in a crowded market with extremely well-funded competitors and they still built a considerable lead in product and infrastructure.
I am saying it does not matter if they are sufficient on their own. If you want to find professional work as a frontend dev in 2021 you will be expected to learn larger and more complex toolchains.
I am sure there are plenty of applications in maintenance mode using simpler tech (or possibly not, because the lower complexity means that there are far less bugs?)
I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.