[slmjkdbtl]

I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.

[nusl]

I'm not on that level, but diving into React when you're not used to it is quite an experience. I've been asked to do it a few times as a most-backend/infra person. Good luck when the codebase is a mess though, cuz it seems like React spaghetti is a special breed of spaghetti.

[cal85]

There’s an interesting assumption here that frontend engineering should always be very simple, such that engineers in other disciplines should be able to hop over and dabble with frontend engineering on the side with no difficulty. Or perhaps the assumption is that React specifically should only focus on the fluffy, junior-friendly end of frontend and leave the more advanced frontend stuff to other toolkits?

[slmjkdbtl]

I think React (hooks) invents a convoluted solution to a problem that can be solved in a more direct way, and there's a lot of big caveats hidden behind the interface that can cause big performance problem and bug. Their invention also requires a specific way of thinking that contradicts a lot of programming intuitions. Complexity is definitely fine if it comes from the problem itself (rendering), but for React most of the complexity is introduced by itself.

[worble]

I'm confused why you feel embarrassed? Do you think they feel embarrassed that you can write React yet don't know how to write patches for the Linux kernel?

It's a different domain with a different skillset.

[slmjkdbtl]

I meant I was embarrassed that these experienced engineers have to put up with some of the bad parts (I think) of web dev, that React (hooks) has a lot of unnecessary complexity and requires some unique mindset you have to train specifically for, unlike other frameworks have more direct and more intuitive solutions to the problem and I believe will be trivial for these engineers to get a grasp on.

[lakpan]

React is fine, but what is going on with RTK? So. Much. Boilerplate.

[acemarke]

Hi, I'm a Redux maintainer. I'm kind of confused by your comment in a couple ways.

I'm not sure why you're jumping to discussing Redux here - we're a completely separate project from React, and nothing about the parent comment mentioned Redux.

That said, we specifically created and designed RTK to _eliminate_ boilerplate, so I'm not sure what "boilerplate" you're referring to here. Could you give some specific examples? What concerns do you have?

[lakpan]

I’m neither a React nor Redux developer, but I work on React codebases. The code I see for simple changes is super verbose compared to what it would look like with simple hooks. I don’t know if it’s just my coworkers that suck at it.

[acemarke]

Redux will never be the _absolute_ shortest way to write updates - it intentionally adds a level of indirection (the concept of "dispatching actions").

That said, we specifically created Redux Toolkit to drastically simplify standard Redux usage patterns. Sadly, despite it being the default way to write Redux apps for several years now, there's still a lot of legacy Redux code that isn't following our recommended patterns.

See our "Migrating to Modern Redux" guide for details:

- https://redux.js.org/usage/migrating-to-modern-redux

as well as the "Style Guide" best practices page:

- https://redux.js.org/style-guide/