I don't think frameworks make any difference in this regard. The most important thing to remember is that developers are people. Most everyone benefits from direction and guidance without regard for their seniority. Some of that guidance can be automated by applying appropriate limits or certain safeguards to the process, but is generally not something that can be outsourced directly to a tool. I think of that as something akin to letting a television parent your child.
They do though, frameworks are just an amalgamations of patterns and practices codified. If you go Vanilla JS you are going to build abstractions on top of it to make your patterns and practices reusable and structured. Given enough time you are going to build a framework that enforces your patterns and practices. So why not just adopt proven ones out of the gate. But verify that they are indeed proven ones before just jumping on a bandwagon.
An example I would highlight is, Redux it's great and it has helped a lot of developers that don't know state patterns learn to deal with state, but it only taught them half of what they need to know. The other part of state is not allowing applications to fall into an inconstant state that it should not be in. Redux intentionally ducked this one because state management is a complex task and building a state machine makes the cognitive overhead much more complex but that is what developers following correct patterns should be doing, they should be using a state machine and it is the reason I use XState in my projects over using Redux as it is a full state management solution, that gives me a guarantee that my state is both preserved and consistent.
> Given enough time you are going to build a framework
I have heard this argument countless times over the last decade and its not based on anything. I suppose if you have never written code without a framework and for the first time attempt to write some new application it would make sense that your application ends up looking that thing you are familiar with. Beyond that this entire position is absolutely meritless.
What I find most frustrating about this sentiment is the lack of originality it codifies. Many JavaScript developers I speak with online are absolutely certain the language is limited to building static pages and SPAs. That's it. And, it absolutely blows my mind that their imagination is so immediately limited. Logically, though, since there is nothing else to build but SPAs and frameworks are great at building SPAs it must not make sense to even not use a framework. That line of thinking leaves me speechless, literally. I just spot responding and walk away.
I started with Motorola 68000 assembly in the late 70's early 80's (hobbyist not old enough at that time to work) while their where frameworks of sorts back then there really was not what we have to day. I can assure you though when you built stuff of enough abstraction you ended up with your own frameworks that helped you build new applications. Patterns of the way you do things and tried and true methods. Packaged up into reusable libraries.
You see it in every discipline, game programmers use game engines which are frameworks almost nobody is writing their engine from scratch because they don't need frameworks.
Enterprise programmers have saleforce, SAP etc. Hardly anyone is writing an ERP from scratch.
It's not that a lot of people that use frameworks don't know how to go it alone, I certainly do and most of the caliber of developers I work with certainly do. It's just that we realize we will, in the end, end up with something that looks like a framework. Because there was a day and time when that's exactly what we did and it was common practice. But that practice came with the additional overhead of training people on an internal framework, as well as maintaining documentation and the codebase of said custom framework.
It was more common and more acceptable before the internet and opensource that a developer or team would roll their own framework, create their own patterns and procedures and it was a very common practice to roll your own framework. But their where commercially available frameworks at the time for things like computer graphics, UI etc. Frameworks are a natural evolution of code reuse. The difference is today people tend to agree on third party frameworks as a standard way to develop as opposed to internally develop them. IN a effort to externalize, training, support and documentation of the framework.
I understand your frustration with developers conflating a simple page with SPA's. I only build large SPA applications I am not a web page developer, but if all I needed to do was provide a landing page, I would not use a framework because 90% of the deliverable is HTML and CSS. It's a lot of overhead to bring in something like React and the NPM build ecosystem because you have one tiny component of an otherwise static page.
