In theory yes, but in practice even with frameworks codebases can turn into messes, and/or tends to become solid but completely frozen on a particular feature s

In theory yes, but in practice even with frameworks codebases can turn into messes, and/or tends to become solid but completely frozen on a particular feature set. Small changes suddenly becomes daunting because the initial architecture needs to be changed to accommodate and surprise all is tightly coupled under the cover. With vanilla JS and spaghetti it's painful and boring but at least if I need to change a behavior on a page usually I'm done with a few lines of code. Edit: it's a tradeoff, but in early stages I found being able to make one the fly changes in a few minutes/hours to accommodate a customer instead of weeks (or never if it's too painful to evolve the perfect architecture) very valuable. It really depends on the use case, and sure frameworks are awesome in the right context, but I think the current "best practice" of defaulting to one in any project no matter the business trajectory, product market fit maturity and team size is misguided.