Earlier quoted context omitted.
I don't think this has to be true. If you think of a framework as a piece of code that calls you where you sort of supply it with configuration you could do that when writing vanilla js but you don't have to. When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.
I mean in a complex enough application you'll have to come up with some abstractions that will make you life easier anyway. I doubt that you will manually add and remove classes, or add and remove nodes via direct DOM API calls every time you need to do that. You know what I mean? A set of such abstractions is what I call a framework. It doesn't have to be a separate file called "framework.js". It may even be more of…
const tag = (tagName, props, ...children) => {
const el = document.createElement(tagName)
for(let k in props) el.setAttribute(k, props[k])
for(let child of children)
el.appendChild(typeof child == 'string'? document.createTextNode(child) : child)
return el
}
The main advantage I think React brought is breaking the concept of "separation of concerns" (keeping css, html and js in different files even when they change together). Keeping stuff that belongs together in the same file and mostly pure is what gives the most benefit. You don't need complicated frameworks for that.
const createSpecialButton = text => tag("button", {style: "background: purple"}, text)
I wrote a figma clone (see other comment) with couple of these utility functions. It looks a lot like a regular react project really. Mostly functions (which you might call a component if they return HTML), mostly pure or local state.