I should start with a disclaimer; I am not a linguist, though I have considerable expertise in my own language (naturally), varying levels of proficiency in three other European languages and a smattering of two more. I'm interested in the relationship between language and complexity in the computer world, compared to that in the world we all inhabit. So please bear with me while I approach the subject in a roundabout manner.
The word 'language' is interesting. In Italian it's lingua and in French, langue. Both of these are closely related to the word for "tongue", and in fact we sometimes use that in English too, for example as in "mother tongue".
But in the English-speaking world we never refer to a computer language as a tongue. The reason is simple; you can't speak most computer languages without sounding like a gibbering lunatic or an unfunny version of Victor Borge.
I recently finished reading a detective novel, written in English and set in Jakarta. It was peppered with Indonesian words and phrases, plus several Dutch ones (Indonesia having once been a Dutch colony). Although the meanings of these words were rarely explained, it was usually possible to hazard a guess at their meanings from the contexts in which they were set.
The point is, at no time did I regard the novel as complicated. Words themselves do not imbue a written piece with complexity. We either understand them or we don't but the overall impression we get isn't one of complexity, no matter how many new words are introduced. Hard to read, maybe; irritating, sometimes, especially when strange names are thrown in just for effect. The English language itself has more words than pretty well any other, but it's much less complex than German or Italian. Complexity is something different; it's related to structure. A complex novel has multiple inter-twined storylines, a huge number of principal characters or regular flashbacks. These are structural features.
Frameworks bring structure to a language that was originally rather deficient in that respect. However, they also add complexity. Nothing is actually replaced, just added to, and the additions come with complex rules about how they are used. The additions and the rules vary widely from one framework to another and intuition can do little to help with the learning process. This is rather unfortunate since fashions change rapidly and without warning. A developer can spend the best part of a year learning one framework, only to find the only available jobs ask for a completely different one, requiring another massive investment in learning.
This trend can be assumed to continue for the time being, but there has to be an upper limit on how much complexity is tolerable because it increasingly limits the number of skilled engineers able to deal with it. This impacts more on maintenance than development, making it hard to maintain products when the tools that were used to build them were overly complex and, worse still, have become obsolete.
Some may find this surprising, but the first example of this approach came before any of the major frameworks and is still very popular today. JQuery provides a kind of "shorthand" for many of the features required of any coding system that is specifically designed for browsers. It's a half-way step to a full-blown programming language in its own right.
Half-way to what, though? Here we move from the present to the future, where all bets are off. Any confident prediction made today will most likely be overwhelmed by some left-field development nobody foresaw. As someone joked, "Prediction is difficult - especially the future".
AppleScript and similar languages are very English-like in appearance, resembling somewhat terse instructions for cookery recipes, navigation or step-by-step car maintenance. (They don't attempt to handle truly natural language; that's the job of an AI system and way outside the scope of this article.) Their big advantage is they can be understood not only by programmers but by ordinary people, most importantly the owners of websites whose requirements are being captured and implemented in code. As Linus Torvalds observed, "Given enough eyeballs, all bugs are shallow". As users of SQL will attest, a language that both domain experts and programmers can read brings many benefits.
English-like scripts do not look like conventional program code. One significant difference is there's less attention to structure and more to intent. In other words, scripts tend to read rather like the user stories from which they were written. When programming with React or Angular you need to build the structure first. The intent is still there but is often hard to find. With high-level scripts, implementation starts with a very broad overview and gradually fills in the detail.
Frequently the programmer encounters the need for a section of code that is clumsy or inefficient to implement in script. This is usually a signal that some new syntax is needed, so a well-designed scripting language has the ability to accept plug-ins that seamlessly extend the language. This process is very much the way human languages work, creating new shortcuts to describe any complex entities that can be encapsulated in a succinct manner. The human brain welcomes these additions, not regarding them as added complexity but as simplification; new information that can be slotted in with that already existing, often replacing far more clumsy descriptions. Without the word "laser" it would be harder to have a discussion about how a CD player works, for example.
Whether the source language is to be Python or something looking like AppleScript, it still has to be compiled, or at least interpreted. The latter is very inefficient so I won't consider it further, but the opportunities for compilation are steadily growing. I mentioned transpilers earlier, but as computer hardware gets ever more powerful and software techniques more advanced, self-compilation starts to become possible.
In this scenario, scripts are independent code modules that work with other scripts by passing messages back and forth, so there's no need to understand the whole structure in order to code for it. This reduction of complexity is a key benefit of a distributed code approach.
My conclusion is that frameworks increase complexity but higher-level languages decrease it or at least hold it at a manageable level. For the time being the former are where all the action is, but they are steadily outgrowing our ability to keep up. It's time for alternatives to be created; preferably ones that increase the accessibility of coding, not preserve it as the domain of a shrinking pool of highly specialized professionals.