This kind of thing is much much less pronounced in the Python ecosystem, but also existent, while many packages are written based on bad conceptual foundations, just like many (majority?) of NPM modules are.
This kind of thing is much much less pronounced in the Python ecosystem, but also existent, while many packages are written based on bad conceptual foundations, just like many (majority?) of NPM modules are.
Part of being a good frontend lead is personally is not falling for the hype, and only adding packages I know will a. be supported for the foreseeable future, b. have an exit plan if those technologies aren't supported, and c. keep an eye on my juniors/seniors to make sure they're writing sensible long-term code.
The gnashing of teeth over the "upgrade cycle" I think speaks to poor team planning/leadership than it does for the actual tech now.
As a full stack developer, your chances of being or becoming the frontend lead are reduced, as you don't have focus like a frontend only person, who will play that card subtly, that they are the specialist and you are not. And frankly, as a full stack developer, why would I even want to become a frontend lead and sacrifice the part of development, that is much saner? For the frontend lead it also pays well to follow the hype, raise the frontend to "modern level" and get paid senior salary.
That's your choice, but myself personally, I like the deep focus on one thing along with guiding my team. I think we perform at a pretty high level and we are a happy productive team by all reports.
Our frontend is sane and that was because I was given the scope to make it sane. Others will have different experiences, and I agree that full-stack would have less sane by default, due to the lack of time or care for it.
Besides that, people tend to jump to the extremes in FE. Want some component (in terms of React component)? Immediately they think the whole site(!) has to be a whole React FE, because they like using sledgehammers. Most people don't even think about serving dynamic widgets only on the very few pages/parts of a platform, where they are needed, using frameworks which have this capability for many years now (for example VueJS), and keep the rest of the entirely static website just that. Static. Workable on by any capable software developer or engineer. No. They must build themselves a FE moat! Make things ever more complex, to justify their roles. When you step back and look at what their site actually does, it is extremely laughable, how much time it took to get there and how much time still goes into it, maintaining it.
The examples I wrote about earlier are not just imagined. I have personally witnessed multiple FE people taking 3 weeks to switch out an app router for a pages router (or other way around) in a nextjs project. This is a problem entirely of their own making. 3 weeks for 3 people, that is 9 work weeks. Someone please transfer 2 months of salary onto my account!
I know how to make completely responsive and well accessible websites, more responsive than 99% of websites that call themselves responsive. More responsive than what most FE people cook up with their JS frameworks and non-standard component systems. That is because I care when I build things and I inform myself about how to do things in standard conform ways and use HTML in the way its elements are meant to be semantically used. I have done FE stuff before. In 20 years my site will probably still work just the same, and it will be simple to maintain, because it uses standard HTML and CSS. Meanwhile their frameworks will be long abandoned for the next shiny thing by then. They will rebuild and rebuild and churn and churn.
Still, managements will rather trust a FE(only) dev to build a convoluted mess, because they label it as "modern" and want to jump on the hype trains. FE devs are often like drug dealers figuratively speaking. The incentives are just like that. The more complex a thing they build, the safer their job. Same is true for backend btw. There are lots of grifter out there.