[jkaplan]

I agree with a lot of these points, but differ slightly in two regards:

1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns.

2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product landing page), then yes it's overkill... but so is something like Rails/Django! Just use a static site (+ generator, if needed.) If you're building an "app"/you're interacting with a database, then you're almost certainly going to want end up wanting interactivity. And it snowballs -- a little state change here, an ajax call there, and all of a sudden your front-end is ballooning without structure or modularity.

[waingake]

Yes this. The article mentions the following as poor candidates for client side rendering. I can agree with blog, but suggesting a tool like React is a poor choice for a shopping cart is naive.

> Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites.

[kristopolous]

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years.

It's made me want to leave the industry completely and I honestly think I will after this project.

It has single handedly slaughtered and destroyed my quarter century love affair with programming.

It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy that's fluid and always changing. So you get a pile of inherently unmaintainable, unavoidably messy code that is deprecated the day you write it.

It's sheer insanity. Trying to get horizontal communication between components.

I'm slapped and told "no don't do it that way" and then I'm given half a dozen extraordinarily convoluted ways to do it instead.

They say "you aren't thinking in react". There is no thinking in react because there's a bunch of different ways to go about it and each one fights against the limitations voluntarily imposed by the framework.

Each one is a hack to get around the needless artificial barriers that exist there for no damn reason other than to make life harder.

Pass a parameter with an onclick handler. Again, I get slapped around as no that's not how it's done.

Why isn't it easier? Why is the Framework requiring me to do more work, to set up an indirection? Why am I working more with it then without it? Why does it give me less, do less, and require more from me?

It's literally the most complicated convoluted and elaborately complex way to do what should be simple and direct things. Every task gets a layer or 4 of complexity slapped on top of it.

It's like they replaced Galileo's chart with epicycles because they have to appease some invisible theory gods.

It's theory that has literally zero hard evidence as to why doing something directly is bad but doing the same thing with a bunch of weird generators callbacks and hooks is good.

In my 5 years of working with it, it's always without failure been the worst catastrophic mistake on every project, blowing through budgets and deadlines like nothing else.

Productivity is slaughtered. Otherwise 10x engineers become 1/10x. It's remarkable how much it stagnates and destroys everything.

This is pure Jim Jones cult magic stuff. It literally only exists to make people feel special and elite while doing what should be simple stuff.

I'm quitting engineering after this thing ships. I simply do not have the words for how much I despise react. It's the most despicable creation I've ever laid eyes on.

I honestly want to have absolutely nothing to do with programming now. After React it makes me physically nauseous.

[onion2k]

I find it slightly incredible that someone can describe React as "the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years", have a whole bunch of complaints about how bad it is, and how it makes no sense, and how it reduces their productivity by a factor of 100 ... and then also use it for 5 years.

[kristopolous]

Sorry, did you want to get on a call? My email is in my bio

I can go over all of it with you.

Really. Maybe 30 minutes, I'm pretty fast

[jkaplan]

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it.

But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on.

Sounds like you've worked in really bad React projects (and/or really good non-React projects). All I can say is that my experience has been different! Redux + Redux Toolkit (https://redux-toolkit.js.org/) helped me and my team establish React patterns that were organized, concise enough, and performant -- although we did still have to tinker and try some things out until we found the patterns that worked for us. Hope it helps!

[kristopolous]

Here's things that are super simple to do with Javascript but extraordinarily difficult in react:

* a function your code can access

* data your code can access

* a dom node you can access

The very core parts of basic programming have been slaughtered and perverted in some kind of repulsive overengineering porno show.

I've worked 3 months on something that should have literally taken 2 days. React is giant sack of bullshit that's made it take months.

Instead of managing say a global object there's this sheer utter insanity of redux store. Something that I could explain in 10 words now takes 9,525: https://www.valentinog.com/blog/redux/

The pythonic notion of "we're all adults here" has been replaced with "we're all completely utterly incompetent children here that need safety locks on everything". I no longer know what works.

I'm actually astounded, I'm not joking in the slightest, in any way whatsoever that

   var a = 10 + 5;

still works and I'm not forced to do something like:

    let a = [...new Array(10).fill(0), ...new Array(5).fill(0)].length;

as a workaround.

I am quite literally shocked by this. Just thinking that this is still possible made me actually shout in happiness at my desk. I really just did that.

I wish I was being sarcastic. I'm not. React breaks programming that much. At that fundamental of a level. It's that profoundly bad.

Coding in react is like if you wanted to get out of bed and take a shower but then find out your town has been carpet bombed and you're sitting underneath piles of collapsed concrete. So first you need to survive the day, get rescued, clear out the rubble, then rebuild everything, then you can go take the shower. Shit's so much easier this way!!!

No.

No it fucking is not.

Just no.

This vile framework is the most vulgar code in an already repugnant front-end javascript ecosystem. It's utterly shameful.

[rw3iss]

Amen! Have been waiting for a react replacement for ages. Hate using it for all these same reasons. Use preact, but mostly same issues.

The fact that they change the seemingly every few months, and have the entire framework scattered around 3-4 different libraries that are always changing is annoying enough.

Oh you want to set the class of the html element? We're gonna rename that to className cause it's easier to read and and we can.

Functional components and hooks become a ridiculous mess too, in any more than basic scenario.

[kristopolous]

Here's another example. Say in javascript I want to navigate to a page 'login', here's a way to do it.

    window.location = 'login';

And there I go!

In react, well it really depends on what version. If I'm doing pre-hook (pre 16.18 or so) classes, first I need to make sure my constructor brings in props that I call a super on.

Huh?

No no stay with me. Then I have a this.props.history object and I push a new entry on to the stack like so

this.props.history.push('login');

Remember to make sure you use the fat-arrow to pass the this reference downward and that you export your class using withRouter. Effectively here's the replacement code:

    import React from 'react';
    import {withRouter} from 'react-router';
    Class A extends React.Component {
      constructor(props) {
       super(props);  
      }  

      fn() {
       this.props.history.push('login');
      }
    }

    export default withRouter(A);

And even then you may still have to "debug" this because it may "break" for inexplicable reasons. Because "In order to make use of history in the App component use it with withRouter. You need to make use of withRouter only when your component is not receiving the Router props,

This may happen in cases when your component is a nested child of a component rendered by the Router or you haven't passed the Router props to it or when the component is not linked to the Router at all and is rendered as a separate component from the Routes."

Again, we are replacing:

    window.location = 'login';

That is our only goal here

How is this easier then the first one? It isn't.

What problem has been solved? None.

Does it take less time? No.

Is this less typing? Less code? No.

Less complexity? No.

Are difficult things less difficult? No.

Fragile things more robust? No.

No none of this. It runs away from more reusable, self-contained, portable code as fast as possible. It gets in a rocket car and fires up the engines to go Mach 1 in the wrong direction. It's a giant tangled spaghetti dish of the worst anti-patterns in software engineering as a requirement for it to work.

[kristopolous]

For future readers, a flagged dead sibling comment said this

> Poor child. Wait until you have to build a sufficiently complex web app. Global variables are never the answer

"never the answer" is a Fundamentalist Orthodoxy.

Look at those words, "fundamentalist" and "orthodoxy".

When they are the answer and are needed then instead of a basic global thing some bizarre fundamentalist mind palaces get built. There's say "a singleton object that expose shared properties through a getter/setter pattern" or some other word salad to avoid using the word "global" and avoid making the code look like a global.

So weird rules get piled on, maybe some ornate calling convention.

These people dress up a global and disguise it in a sufficiently large enough costume so their fundamentalism doesn't get offended.

It's simply blind dogmatism and utterly indistinguishable from any other cult-driven purity test.

The ceremony is a necessary delusion so they can maintain some imaginary tribal membership to some fiction of "senior developer" they have constructed out of bad advice and empty platitudes by other misdirected self-assessed experts.

It's like the anti-climate-change or anti-vaccine people who think they are smarter than everyone; ignorance breeds a confidence that only progresses the pursuit of greater ignorance. Like astrology, these imagined worlds are far richer and more complicated because they have to construct something that follows arbitrary rules and disagrees at a fundamental level with basic realities to prop up mythical narratives holding their tribes together.

What a way to build things.

[acemarke]

Glad to hear that RTK is working well for you!

Out of curiosity, what sort of "tinkering" did you find yourself doing, and what sort of patterns did you end up with?

[jkaplan]

High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally).

If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers, since they're in-lined. I can't remember if we ended up popping the reducers out into their own functions so they could be next to the createAsyncThunk call, or if that created too much of a typing headache and we just dealt with having async action creators declared at the top. (We also tried just using createReducer directly, but iirc the typing was just extra work compared with createSlice.)

**

Only partially-related to RTK, but the other thing we had to tinker with a bunch was performance. RTKs default use of immer helped a lot, and I believe we also ended up using createSelector (or perhaps the Reselect API directly) in a few places. We also had to learn to make extensive use React.memo and React.PureComponent. Redux dev tools were incredibly helpful for figuring all of this out.

*

Anyway, hope that's useful/interesting! RTK made a big impact in my day-to-day React/Redux development, from "ugh so much boilerplate I feel stuck" to "I can make changes reasonably quickly." Hope to see it continue to improve!

[acemarke]

You should be able to write thunks in the same file as `createSlice`, usually in front of the `createSlice` call, and then use the `extraReducers` "builder callback" syntax inside the slice to handle the various actions dispatched by the thunk. See the example here:

- https://redux-toolkit.js.org/usage/usage-with-typescript#typ...

And yeah, `createSelector` _is_ the Reselect API, just re-exported.

You might want to also take a look at our upcoming "RTK Query" API that will be in Redux Toolkit 1.6, which should be out in the next couple days. It's a data fetching and caching layer built specifically for Redux usage. The preview docs are here:

- https://deploy-preview-1016--redux-starter-kit-docs.netlify....

[jkaplan]

Ah yes. We did end up using extraReducers, but didn’t love that the thunks and their corresponding reducers had to live in separate parts of the file. (For me at least, mentally simpler to have an action and it’s reducer close together.)

This looks cool, thanks for passing along! I’m actually starting a new project now, and deciding what my state management / caching layer should be, so great to know this is an option.

[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.

[joelbluminator]

Hey woha wow hold on a second. Quitting engineering over this? Just find a job thats pure Rails / Django / .NET. Those jobs are around, usually its smaller projects companies but they are super pragmatic. Anyway quitting is extreme, take some time off you are burned out probably.

[wonnage]

I'm sorry you have this experience. I think the most confusing part of React for me was that even though JSX looks like HTML, you're actually not interacting with HTML at all. At its most basic you're just giving React a `[{ type: 'div' }]` and it will create and manage an actual <div /> for you.

[kristopolous]

it's not that. it's the rationalization through imagined differences. A forceful separation and grouping of equivalent things into difference categories and a dictation of their interaction by segregation in the name of more "organized code".

Things do adhere to a structure under its guise, it's an accurate statement. But it's an arbitrary one that's of dubious and most likely negative value.

The reality of maintenance, deadlines, budgets and number of engineers working on the projects seem to suggest the impact is overall negative.

There's two reasons this stuff sticks around:

1. Counterfactual testing can't ever be done to test without ... You can't rerun the project with the same initial conditions and do some kind of clean demonstration of it being a hindrance.

2. Even if #1 was achievable, there's other reasons people do not want to admit to it. And this is especially applicable to an authoritarian framework such as react that enforces doctrine by explicitly disallowing heretical code

Political scientist Adam Przeworski claims authoritarianism can reach a stable configuration "mainly on lies, fear and economic prosperity":

* There needs to be an economic value to the doctrine perceived in the mind of the prospect.

* There has to be a fear of losing out or falling behind by not adhering to the orthodoxy

* The core claims have to be fundamentally, exhaustively and obviously fraudulent.

React checks #1 and #2 and for #3 they claim simplicity, painlessness, ease of use, all of these are profoundly fraudulent claims as anyone who has extensively worked with it knows.

This is why it's become a stable authoritarian system.

[toastal]

But you also never had to use JSX and the old docs showed without.

[hackerfromthefu]

Oh the honesty, it burns, it burns ...

Hey give server side blazor a try if you want to restore your faith in modern but productive and simple solutions.

[1ark]

Gamedev (w/o big engine) or terminal apps in your favorite language! Lots of freedom to be had in those environments.

[Mike86534]

That's why I am a happy backend developer. Quit frontend and move to the backend where development is straightforward.

[kristopolous]

oh sorry, one other thing, jkaplan, are you THE Jerry Kaplan of Go? The writer of the fantastic 1994 book "Startup" that I have on my shelf?

[jkaplan]

Nope (if only!)

[kristopolous]

The book is pretty great. I'll put it with "The soul of a new machine", Ferguson's "Computer Wars" and Lapsley's "Exploding the phone" as top narrative tech books.