Maybe React itself, but everything else that goes into doing react development; design patterns, gotchas, testing, webpack, native and so on? That takes far longer than a day, and is what most would expect when being able to really say they "know react".
Also, many of the concepts you need to learn for proficient react development are auxiliary to react and could be applied to vanilla JS or really any UI framework. Any UI is fundamentally a state machine, and solutions to implementing it all require state management and clean separation of the presentation and data layers.
https://github.com/facebook/create-react-app/blob/master/pac...
The README included on a project generated through CRA is 116KB. A screenshot of that page rendered in GitHub is 60054px tall.
Honestly, I don't know if this could be made simpler or easier. React and its ecosystem deal with complex problems that can't always be reduced to simple explanations. In the case of this README, of course a lot of it is about specific setups that most beginners don't need to care about, but that CRA, being the blessed point of entry, still should support, or it would lock everyone into a Facebook workflow.
I think many developers would be better served by entering frontend development not through React, but through the basics (HTML, CSS, JS) and other ecosystems.
[0]: Unrequested opinion: frontend developers reach for bigCo solutions — whatever Facebook/Google/some billion-dollar startup uses — when smaller, lesser known, "boring" or exploratory solutions could be better, trying to solve problems they don't have.
At my last company, we found the opposite to be true. Switching to React made hiring all but impossible. Our Ruby devs mostly refused to learn the new stack and left, and most of the people we did hire to replace them were Java developers. I only met one hire who was immediately productive on our stack and she said it's because she had spent the past few months learning programming for 70 hours a week (!). She left 3 weeks later for a better paying job. Front-end development is absolutely bonkers right now.
For example, I am glad I did not spend more than a few minutes looking at Coffescript.
You can't build an application using React alone. You also need to learn ReactRouter and Redux, which add lots of complexity. Not to mention, if you spent only one day learning React you're probably going to do it wrong: you have to learn things like where to put state, when you have a hierarchy of components. Learning the "ten functions" of the API isn't enough!
To answer part of your question, Promise.js has become formalized in the ECMAScript standard, so maybe not the best example.
These frameworks emerge to make it convenient to solve problems that JS does not offer an easy way to solve. I don’t see anything philosophically wrong with that; in fact, I would argue it’s a big driver of JS adoption. Prototypical inheritance makes it very easy to bend javascript to your will.
If you don’t like the frameworks you don’t need to use them, but it’s going to harm your career if you actively avoid learning how to use frameworks that are deployed with increasing frequency on new projects.
The other advantage of frameworks is that they provide common idioms and enforce procedural standards, both of which make working on a team more productive as everyone has the same base of understanding. They also make it easier to hire for that team.
Try implementing any sufficiently complex app in vanilla JS and you’ll likely end up recreating many of the aspects of popular frameworks, except your “internal framework” will be messy, undocumented, and unique to your project, severely reducing maintainability and increasing onboarding time of new developers.