Can definitely agree with his pain point about forms. I've been through most of the libraries, and the one I liked the most was Formik, because it felt like I could actually get something done. react-hook-forms is beautiful when it works, but the documentation is byzanthine - even when I know exactly what I'm looking for (and I've seen the page before), I often can't find it.

The part about Redux and Context seems to be a complete misinterpretation of what Context is meant for. It was never meant to replace Redux, and as far as I know nobody from the React team has ever claimed something like that. State management in React is a topic discussed to death, there are plenty of options if you have specific tastes or requirements but plain old React state works perfectly fine as well (especially when coupled to server-side state libraries like React Query). But Context is not about state management, it does not seem useful to complain that it doesn't do a job well it was never meant to do.

The part about the Inspector component and the rules of hooks I don't understand. I would have put the visibility state outside the Inspector component, and then there is no need for any conditional calling of hooks.

One could argue that it's not that React can't handle increasingly complex situations for you and that's why you spend more time on them, but that frontend as a craft has evolved due to React having solved the easy parts and has raised the bar, and therefore these complex situations belong to the next breeding site wherein the community is arguing about new solutions all the time, at the current time. It's healthy to retrospect how we got to this breeding site, yet there's always a certain doubt or even bias that what brought us here today is not what takes us forward tomorrow.

It's like the reverse of Shiny Object Syndrome.

I think the title is a reference to this wonderful song by LCD Soundsystem: https://www.youtube.com/watch?v=-eohHwsplvY

> What's next for us? You tell me.

I'm gonna say something crazy here, but hang with me: hypermedia.

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React.

For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to solve a complex DOM state issue with custom hooks wrapped around refs.

Newer tools like Svelte and Solid do look promising as far as removing boilerplate, but they personally feel a step too far off the path of “it’s just JavaScript.”

Has anyone else here successfully left for greener JS pastures?

I must be the only person in the world who likes class components in React.

Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

Maybe I’m a React apologist, but this list of complaints seems mostly self-inflicted.

> Form libraries are portly maintained or documented

The two-way data binding in Svelte saves ~4 lines of reusable hook function but doesn’t come close to covering defaults, validation, errors, dependent fields etc - all of that is essential complexity.

Write your own form field hook. The state model for a form is simple - what is a 3rd party library bringing to the table in terms of state management? I have more pain explaining what I want to a 3rd party library than I do writing a bit of code myself to do the same thing. I reach for open-source input components from a vendor for things like credit cards, but manage the state myself.

> useContext and useEffect have annoying dependency tracking; I prefer Solid’s mutable state and automatic dependency tracking.

React’s built-in hooks are positioned as building blocks with clear-cut contracts. Why dump Redux for bare useContext if you prefer Redux’s selectors? Just use Redux. If you like the Solid style of automatic dependency tracking and mutable state, just use Mobx - it’s a mature library for that style that’s been around for 7+ years, and is used in production by products like Linear and Cron.

Overall I agree that function components in React are difficult to get right for developers and a bit too verbose. There’s an onboarding tradeoff to every abstraction you layer over the framework’s APIs, but there’s large advantages too. Do so judiciously to find the sweet spot for your team & scale.

I spent about 2 years at my last job building a greenfield react app mostly by myself (around 10k sloc). I enjoyed it for the most part. But I did run into all the issues raised here, they are valid. I think the worst issue with React is the dependency arrays that get sprinkled around everywhere - in my opinion the framework is unusable without a 3rd party linting tool that points out when your dependency array is missing something. If you accidentally add the wrong value in there, hello infinite render loop!

One of the biggest level ups I had was extracting complex hooks into their own .js files instead of stuffing next to component code. This helps a lot with readability/reusability.

Overall I liked what I came up with, but it felt like a lot of inventing stuff on my own, which I'm not sure if the next developer who comes along will appreciate.

I prefer Angular. I never could accept writing css/html in my javascript. To be fair, my background is from XAML, so declaring the state separately and simply binding to it in my html template felt natural. The whole functional approach in React is overkill imo. It's okay if the state mutates in 90% of scenarios. Where there is really benefit from immutable states, I can enforce that on my own.

I use next.js with react and typescript and mostly it's a good experience

Function components are a useful tool, but for the life of me I can't understand why the community currently builds everything with them.

A lot of React code I run into these days would be simpler and less verbose with a traditional (non-function) React component.

Salut Marmelab

The best way we have found is a custom useForm hook (simple to code, using useState's):

    const { submit, getProps, isLoading, error } = useForm({ onSubmit: cb, initialValue: {} /*optional*/ });

    return (
      <form submit={submit}>
        <input {...getProps('firstName')} />

very flexible, you can use other wrappers than form or input

react-query is another super useful lib, you could use useMutation() for implementing useForm actually

Hmm… let me be frank about my experiences with React. I’ve been using React heavily for far over 6 or 7 years.

React is amazing. And what I see is that people find so many ways to shoot themselves in the foot. At the same time, I understand that batteries-not-included approach will lead to that result.

First of all, people get out of their skin and try to make it a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.

I’ve given the same demo day (task) exercise to ~50+ react devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside react components. The sad part is this app doesn’t need react at all. Or could implement 99% of the BL in pure JS and just call one function from React.

React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singletone instances of a business logic because we’ve “forgot” how to do a DI without a framework. People write `<IF>` components for christ…

Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way, beyond todo examples. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.

In a nutshell, the we should critique ourselves, not the framework. IMO the framework is doing it’s job just fine. Unless we learn what really goes wrong with react projects we are doomed to repeat the same mistake again and again with next (pun intended) framework.

I love hooks, but the main problem with hooks is that when you have a problem, you usually have to fix it in hacky ways. hooks were a revolution yes, but since the foundation was quite weak, everything they added on it unfortunately made it worse.

Been using React as the view library for 8 years worth of applications that real-time manage fleets of robots worldwide (think config CRUD app + Google Maps + Dashboard + live camera/lidar views + joystick controls).

I generally empathize and see what a lot of authors are saying when they have these commentaries. But I just cannot get past the reality that for all its issues and things worth complaining about, React has never really been "in my way" when it comes to the only goal I really care about: shipping a maintainable product on-time.

I think that comparing a 10 year old library to much younger libraries can be useful in some cases, but is still apples to oranges, given that younger library still has to survive growing up and not having the same claimed fate.

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc.

The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each other, half-finished move-to-new-framework initiatives.

I just mean to say that when I hear "it's because React" or "it's because rails views", any other of the infinite variations of this, I kind of just tune out. Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc.

React is bad in the same way C++ is bad. It's not really, but it does take a while to learn the ins and outs. In the end, the pattern React provides is much more powerful when used right. But it's not a one size fits all, a lot of the time you don't need the flexibility if you're new to it and just want to get something done.

I was a huge React fan myself but when I started to use Vue and its Composition API one year ago I had tears of joy in my eyes. You have a setup function that is executed exactly once. Inside this setup function you setup your life cycle callbacks, reactive state variables and so on. This is how I wish React + Hooks should have been. Nowadays I won't even accept projects that use React anymore, exactly because of all the pain points OP mentioned.

SolidJS is following the same principle like Vue + Composition API. I think Svelte is also in the same boat. This kind of pattern is so much easier to use and reason about. React Hooks become really painful and annoying really fast.

I’d argue, although this can happen with other frameworks, the high level of abstraction makes it worse with React. As soon as you’ve signed up with that ship, you’re going down with that ship.

I doubt web devs would ever accept React as the de facto JavaScript framework and we definitely shouldn’t if it wants to keep evolving but most of the articles against react these days seem to be the equivalent of frat boys negging and mocking woman just because it’s the cool thing to do.

I’m sure there are some good points being made out there but those points Are getting lost in the noise which is a real shame.

As someone whose career success was very tied to React, I will say that "quiet quitting React" (or, nonjudgmentally, realizing my longterm interests were broader and taking action on it) has been one of the hardest career transitions I've ever had to do. The money and social validation and temptation to stay within the React-industrial-complex (explaining React to developers who just want the default thing is a very very profitable business) was very strong and I've had private conversations with many folks who got into it not having fully examined their beliefs and now feel trapped in the local optimum of React specialization as a career (which is then a self reinforcing loop as companies see it as a recruiting advantage, leading to devs optimizing for it because companies advertise for it, etc).

React is doing innovative, groundbreaking stuff with React 18 and beyond. I've done several talks on them and will use React when I have those needs. but other folks (I went with svelte in 2019, but i'll also acknowledge qwik, solid, and vuejs) are doing cool stuff too, and most people are usually not building facebook. Ecosystem for React is strong but size isn't everything; once you identify the 10-20 things everyone shouldn't DIY you're basically done (I ended on this at last week's Svelte Summit https://www.youtube.com/watch?v=A8jkJTWacow)