Problem is that you end up spending so much time working against the framework when the framework is too opinionated.
I prefer a framework that tries to get out of the way. It just gives you what is needed to structure your code, so that everybody can find their way around the codebase, and then lets you get on about the actual concrete implementation that you need. Angular instead has sooo many opinions about how you should do everything. So much boilerplate, so much runtime, and so much accidental complexity everywhere.
It doesn't have opinions about things it doesn't have to. It's fast and minimal and lends itself to a clear common code structure. This is what a framework should do.
There seems to be a lot of confusion about what a framework is.
- React is not a framework /Angular is a framework
- JQuery is not a framework / Ruby on Rails is a framework
The fundamental difference between a framework and a library is that a library is passive. It provides reusable code that sits there waiting for the consuming application to call into it.
A framework takes the opposite approach. Frameworks apply the "Hollywood Principle" (don't call us, we'll call you). A framework is a skeleton application already developed for you, having made fundamental design and architectural decisions. It does not exist to get out of the way but to take control and do the driving for you. The idea is that you provide the unique, domain-specific behaviours that are specific to your application and delegate as much as possible of everything else to the framework.
This is a feature, not a bug. Frameworks exist to give you as much scaffolding, bootstrapping, internal APIs and up-front design decisions as possible.
That appeals to developers because it speeds up development time. But it trips a lot of developers up when they don't understand the internals and design decisions of the framework they are using. If you approach a framework with design paradigms in mind that do not align with the framework's underlying decisions and architecture, then you will feel like the framework is getting in your way.
The relationship between a framework and an application built with a framework is very much a marriage. The choice of which framework to use, and whether to use a framework in the first place, is a crucial architectural design decision that must be made carefully. If you make the wrong decision then you would be right to rip out your domain specific code and start over.
My point is there is no such thing as a framework that "stays out of the way." That would be a library.
There is nothing wrong with not using a framework and using libraries instead. My main problem with React and the React ecosystem is that this fundamental distinction between libraries and frameworks is not recongized by React developers and the community. They treat React like a framework when it isn't, complain about Angular being "too opinionated" not recognizing what those opinions have to offer, and then proceed to pull in a million different libraries thinking they're working within a framework while doing the exact opposite and putting next no thought into fundamental front-end application architecture.
I come from the era of Java OOP frameworks like Spring MVC and front-end frameworks like Ruby on Rails. That's why Angular appeals to me - because I understand what a framework is, what to expect from a framework, how I would go about designing my own and what to look for when choosing one.
If you don't then any framework will feel oppressive. The best thing you can do at that experience level is to learn as much about system design as possible, read a book like Building Application Frameworks (Fayad, Schmidt & Johnson), and think about how your ideal React framework (if one existed) would look. Then you will understand the different opinions of different frameworks and will have well informed and defined opinions of your own.
When you write a React component, there are all kinds of ways where React calls you, e.g. the hook mechanisms. And that can be considered a framework in my opinion.
It also tells you how you should write your components, which is another sign that it's a framework and not just a library.
I may not have been clear enough in my opening sentence discussing the differences though I did go into great detail following it and so I don't think my comment was unclear.
By the logic you just demonstrated, if you call a function that accepts a call-back as a parameter, when it evaluates your callback you are consuming a framework. Or any React component that receives a callback as a prop would suddenly be a framework. Promise libraries would be "frameworks."
Just because a framework executes your code primarily via the application of the Hollywood Principle, and operates primarily through the application of the HP, doesn't mean that any application of the hollywood principle automatically indicates that you are working with a framework.
When getting into discussion about definitions, there is a lot of room for nuance, opinion and degrees. The key part of my definition that you glossed over was [paraphrasing myself]: "skeleton application that provides as much scaffolding, bootstrapping, internal APIs and design decisions as possible leaving you free to focus only on the pieces of your application that are specific to your domain problem."
Yes, you are right it's very nuanced and also a bit subjective. So it doesn't actually make much sense to argue about it, much less here. Anyway, thanks for your comments, they are insightful.
I prefer a framework that tries to get out of the way. It just gives you what is needed to structure your code, so that everybody can find their way around the codebase, and then lets you get on about the actual concrete implementation that you need. Angular instead has sooo many opinions about how you should do everything. So much boilerplate, so much runtime, and so much accidental complexity everywhere.
For this reason I prefer Svelte these days. https://kit.svelte.dev/
It doesn't have opinions about things it doesn't have to. It's fast and minimal and lends itself to a clear common code structure. This is what a framework should do.