[mekkkkkk]

I have a really hard time relating to the conclusion of this. In a big React codebase there are certainly a lot of indirection and "artificial" barriers. The React ecosystem is indeed turbocharged and confusing, atleast if you are trying to follow the latest trends.

However, there is atleast a method to the madness. Compared to the bowls of jQuery spaghetti that was used to bring SSR apps to life back in the days, the situation is infinitely more ordered. To say nothing of the absolute insanity that was pre-framework-driven SPAs.

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.

If I may ask, what was your stack of choice before being forced to work with React?

[midrus]

The alternative to React is not jQuery spaghetti or full page reloads. You have solutions that cost a third or less of the effort of doing an SPA (and not as little as throwing in some jQuery) such as Unpoly, or Hotwire.

[mekkkkkk]

I'm only bringing up jQuery because the transition from homegrown jQuery madness to React is still a common upgrade path (even more so five years ago). I'm not claiming React is the optimal choice for anything. In many cases it is objectively the most pragmatic one, though. It has arguably the most momentum and mind share of any frontend technology ever. And it just isn't as horrible as the parent and other posts make it out to be.

[kristopolous]

> 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

[mekkkkkk]

I don't really understand what you are suggesting. If everyone would stop using mainstream frameworks, the result would be endless bespoke ones. As long as programmers want to simplify, innovate and accelerate their work, they're going to leverage and implement abstractions if there is room for it.

I have worked on plenty of projects using their own, homegrown bespoke frameworks, and it ain't pretty. On top of that it is absolutely wasted knowledge that won't translate to any other code base. If you want to argue that it's all incompetence, I guess that's fine. To me it's about familiarity.

[kristopolous]

This imagination that there needs to be a framework is nonsense. It's done by people who have drunk the koolaid and don't have a long view of programming.

The complexity implicating the overhead is an imposed illusion.

All software lays bare the organizational structure that it's created in.

The structures work within other organizations similarly structured.

It's why ruby shops look the same along with php, java, etc. Why it looks like their is a consistency of dynamics among these channels of development.

Some of these institutional structures are healthier and more productive than others.

React, as a codebase is an autocratic hierarchy ultimately run by ignorant indecisive incompetency that fosters cult adherence to achieve ultimately banal ends through a needless level of strife and overhead.

That's effectively most programming teams which is why it's ultimately so popular. It's also why there seems to be so many cocky buffoons in their early 20s doing it.

Those who see a need for frameworks are speaking more to their rigid notions of the organizational structure upon which software is built then upon the technical need at the software level.