"Hipster frameworks" is a strawman. You see how it made people argue? That's so that they can dance around the actual issue some more. You're trying to get out of a failing society and they discuss Berlin and the meaning of "hipster". Here's what they don't want to know:
* There are new people going into software development all the time (because like some other poster said it's one hell of a cushy job). As a result, there are a lot of developers who spend a lot of time learning frameworks because they don't really know the language or the operating principles of the underlying platform/environment. This only makes them replaceable and easy to exploit. Differentiate and build yourself a moat by cultivating a deeper understanding of those subject matters that you personally find most inspiring.
* Churn is especially bad in frontend, but if you are already good at VanillaJS you'll do fine and be productive in any framework. You may even find it fun to learn how different tools solve the same problems differently. This requires you to be familiar with the essence of those problems, and not only the usage of the solutions. I suggest becoming familiar more deeply with the more time-tested tools, as they have the greatest mindshare and the most prolific ecosystems - so, more stuff out there for your to reuse and learn from. "Choose boring techology": https://boringtechnology.club/
* On a related note, if you do find yourself working in the Web ecosystem, I suggest brushing up on the history of JavaScript, especially how the transition from ES5 to ES6 and beyond was implemented. This is the ultimate source of most of the complexity that people have in mind when complaining about framework churn. The proliferation of React and TypeScript, and the related, somewhat forced migration from CommonJS to ESModules over the past 2-3 years, are a continuation of that.
* The "new shiny hipster framework" is a blip on the radar. The chances of being exposed to one in production are low by definition, and you should cherish them. If it's some particularly bad one you might spearhead an effort to replace it with something more sensible throughout, and get experience that will lead to better career progression. What's more likely is being exposed to (a) a specialized in-house framework which cannot be readily transferred across gigs, (b) a mainstream framework which gradually reveals its ugliness as you become familiar with it.
* Working with/on in-house framework could be a great opportunity for learning and applying higher-level concepts across the spectrum from development to business. Mainstream frameworks can be a bit depressing because a lot of them are open source in name only - they are a way for tech giants to get people to solve their problems for free, i.e. once you see what they're doing wrong you can't unsee it, it's all over the place, and you can't really do much of anything about it. Find the one you hate the least and learn how make it do something that its authors totally didn't anticipate - that way you'll know enough to fix it when it inevitably falls apart.
* Work-life balance is not a constant. The learning curve in this line of work is steep but the amount of fundamental knowledge that you need before you can be reasonably productive in any generic developer role is finite. (They say mastery takes 10000 hours. They also say that number is bollocks.) In the end, you gotta put food on the table, and you gotta stay healthy and not burn yourself out in order to... keep putting food on the table. Think laterally, don't get stuck in that loop, and think how to spend time on activities that you, personally, find meaningful.