> Redux is a good example of this. It requires a load of boilerplate and seemingly contrived ways of reacting to interactions. What most people don't understand is that this is the primary feature of it. It is a rigid flow of data that enforces you to go through the same steps each time. As such, you can get into a Redux powered app and understand it relatively quickly.

No this is totally completely wrong.

Tools don't make the programmer competent.

The person that created a mess of jquery will create a mess of react, ember, vue or whatever they are using. They don't become better programmers with more authoritarian tools.

This delusional attribution was supposed to happen with OOP in the 80s, RAD in the 90s, it doesn't work. You can't shove competency into people by enforcing upon them more complicated systems. In programming, bureaucracies, companies, governments, any human system.

Instead what you get is more complicated messes. Look at any Java code for a great example. Or bureaucratic institutions or anything else structured under supposedly all-encompassing ideas. All you've given is a shinier and longer rope to hang themselves with.

It's a long promulgated empirical claim with lots of empirical evidence stating it's dead wrong and does not work.

Javascript, the browser, html, and css, that is a stack. I say <button> and a button appears. I don't have to poke addresses for graphics, implement a line algorithm, a flood fill, define hit points, create the abstraction of a document that moves with a scrollbar or that flows around a page ... literally millions of things are solved.

These tools (JS, HTTP, HTML, CSS) seek to empower and enable, not constrain and dictate. That's the difference. This is why TBLs open system kicked Ted Nelson's Xanadu's ass and why 30 years later he still doesn't have shit to show.

The baseline supposedly "raw" tools are already incredibly high level and sophisticated.

What about your "MVC"? HTML is the model, CSS is the view, Javascript is the controller ... that's why there's 3, that's why they do what they do, that's why they are there.

It already exists. It's already there.

What these frameworks do is go in and break all of that. It becomes one big garbled mess again. Solved problems become unsolved and the programmer gets blocked from using any reasonable solution to get back there. All in the name of the authoritarian appeal that this will produce better code.

It's utterly absurd. It doesn't produce better systems or code, it hasn't ever, and it will continue to not.

Instead it will produce deprecated unusable messes that need full-time staff to babysit the complexities of all the parts and make sure the cathedral of interacting dependencies doesn't catastrophically collapse. That's why these projects have 6-figure salaried engineers on "maintenance". Look at the batshit insanity on the server side with k8s and tools like prometheus these days. It's trying to solve problems by tossing a bag of hurdles and complexity at it. Before that it was chef/puppet.

Sometimes these days I see both k8s and chef on systems that have become magically more broken and have more people working on them with more downtime than they were before.

It's why these things are constantly "rewritten". Because the old authoritarian complex thing is finally acknowledged to be inadequate when enough reality finally seeps in and then they run off to the next one hoping that once again, documentation that reads like a book on astrology or homeopathy will be the silver bullet to their problem.

Fred Brooks lobbed this same criticism in 1987 and it's still true today because although technology has changed, humans haven't. https://en.wikipedia.org/wiki/No_Silver_Bullet