This article categorizes the code components used to build a modern web application, dividing them into Frameworks, Libraries and Languages. I'll describe each of these and offer an opinion about why the way we structure a project frequently results in things not turning out as intended.
A Framework is software analogous to a new house without windows, doors or furniture. The structure is all there but you have to supply all the detail yourself; all the bits that make it into a home. It's quite easy to spot a software framework; it follows the Hollywood principle of "Don't call us; we'll call you". The framework is very much in control; you are not.
A Library is completely the opposite; it's code that is called directly by your application, providing "black box" functionality as required by applications. Here you are in control. Libraries are a vital part of any software system and the value of a library is often closely related to the care taken in defining its API.
Now for some examples of each of the three categories.
Angular is a framework and proudly announces itself as such. Although I have very little experience of using it I believe few would regard it as anything else. In order to create a viable Angular product the structure must be defined up front and then everything made to conform to that structure. This is for some excessively rigid but for others a guarantee of a superior outcome.
React is also a framework, but - as I understand it - with a nod to being a library as well. The framework is less rigid that than of Angular, and for anyone brought up on imperative coding it may be somewhat easier to learn. React was developed by and for Facebook; some believe that makes it good for everything while others place it with Angular as overkill for smaller projects.
So, what is the match between the three concepts and the kinds of product being requested by customers?
Client side programming ranges from very simple interactivity added to a static web page through to huge commercial, industrial or social media websites. It's rather foolish to assume that the same tools are equally applicable in all cases, though looking at the skills requested by potential employers that tends very much to be the assumption. I put most of that down to ignorance and the herd instinct.
As with houses, changing the structure of a large software system is an expensive business, so frameworks work best where the structure is unlikely to change. Paradoxically, that makes a library component the ideal place to deploy a framework to maximum effect. Once written, the structure of the component will rarely be changed, and if it's a popular library it will have a development team dedicated to its maintenance over a long period. One of the best examples is Google Maps. Few users of this amazing library have the slightest interest in knowing what goes on inside it; all that concerns them is the API it presents to the world. It would be inconceivable for Google not to maintain the expertise needed to support and continue the development of Maps.
Websites themselves, with relatively few exceptions, do not remain unchanged for long. When change comes it's frequently structural, as often as not driven by a desire to "look different", and this presents a problem. In a nutshell it's that software tools are designed to help developers become more productive. All the emphasis is on creating a product, the assumption presumably being that once developed and deployed the same team will continue to provide maintenance. But this is only true for companies who are themselves software houses. For everyone else, the development team, whether in-house or contracted, will move on. It's hard to justify maintaining expensive developers when you only have occasional work for them.
As I said above, structural changes are expensive. Before you can even start you have to get the people up to speed on how the system currently works, in order to then make it do something different. It can take months for even the best programmers to get to grips fully with a complex system, and in most cases months is what we don't have. The result is inevitable; changes are made by people who lack a complete understanding of the system, resulting in code that will baffle future maintainers and damage that will be even harder to deal with next time a change is needed. And so on, a spiral of bloat, decline and "death by a thousand cuts", until the cost of maintenance exceeds that of abandoning the product and starting again. Usually years before coming to the original projected life of the product.
I've seen this first-hand more than once. In one case I joined a large pharmacy chain whose main software product was maybe 5 years old and was rapidly becoming an unruly pile of spaghetti. There were only 3 people who really understood it; one left a year after I joined and the other two were contractors. With a change of ownership the company then decided to cut back on the latter because of the cost, so those who remained never had a perfect understanding of how the system worked, nor was there anyone left to ask. Naturally there was no software documentation - we were expected to be experts who could "read the code". We couldn't, of course; few can, any more than the general population can read and understand legal documents, whether written in English or a foreign language. Eventually the product was abandoned and its place taken by a standard off-the-shelf system; expensive and with fewer features but none of the problems of maintenance.
No matter how hard the industry works at creating new structural entities, the results will never be understandable by the great majority of those charged with maintaining the products. They're simply too complex and the tools used to build them go out of fashion too quickly. As long as we continue with the same mindset, projects will continue to fail early.
And that's the basis of my plea for an industrial-strength language for browsers, that uses English-like scripts to convey meaning and preserves readability by everyone from the owner of the site to the browser it runs on. Since I believe in practicing what I preach I built my own compiler and I get very good results with it, but I'm not an expert in that field, nor am I in the same intellectual class as the people currently developing frameworks like Angular and React. I can barely imagine the power and beauty of what might appear if that amount of effort were to be expended on devising and implementing a form of English that allows people of all abilities to truly "write" websites and web apps and then keep then running for a decade and beyond, but I long for the day such a system arrives.