Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in

Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in the stack. This is after all the most precise information you can put in a job description that is actionable by a recruiter/HR-person. But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture. Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.