React is holding me hostage

People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless.

VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics.

The killer feature for React was - 1. JSX - typing and auto-complete for components, colocation. 2. No direct dom access. (Good bye $element)

Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript.

Luckily none of the other frameworks, even Angular, have rampant direct dom access anymore.

Hooks aren't a problem in general. It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed. And it was clear from the start it'll be a pain from the limitations around it. It requires a mental model detached from everything people are used to and from other things around it.

When using React I usually just use MobX and everything just works.

People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead.

I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people, and if there's an issue you can be fairly sure that someone else out there has had an issue too and there's a solution to be found.

I'm not in a hurry to replace React, but I don't need to. React is stable enough to rely on in my honest opinion.

Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain.

The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected side effect and redraw and explaining how `useMemo` and `useCallback` actually need to be used [0] and made me think of Stephen King's Langoliers.

It occurred to me that "React is the new IBM" [1] It has become so dominant in the market that no one can get away from it. But that also means that it can no longer innovate. Andrew Clark's twitter post *acknowledging* that signals and fine-grained reactivity would be better for performance but that the React team doesn't care pushed me over the edge of frustration.

I think that React finds itself not too far off from where IBM was at the micro-computing revolution. IBM had become too beholden to its market and too arrogant in their own success to see their own downfall.

The traffic and feedback on the second article is an indication that there are a lot of folks out there who are really, really dissatisfied with the state of React.

[0] https://chrlschn.medium.com/8eb7bb72c87

[1] https://chrlschn.medium.com/react-is-the-new-ibm-6af2f4b04e5...

I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird.

I think this highlights part of the problem with React and most other frameworks - people expect too much from them. If you're delegating all of your coding skill to the framework and expecting it to just magically work no matter what dodgy code design you throw at it then you're going to build a shitty app. You have to remember that you still have to think things through, use your skills as a dev, understand what's happening and why. That is always going to be true. You're always going to have to put the work in.

At the beginning of the article the author says they feel trapped by React because their previous, current, and next jobs are all going to be React based. That isn't true if they choose to put effort into learning other technologies and seeking roles that use them. If you work hard you find options open to you. Heck, they could move out of web and start writing completely different code that isn't even JS if they felt they wanted to. No one is being held hostage by React. You are only held hostage by your own fear of doing something hard. Feeling like you have to stick with React is a state of mind - you can change that with enough effort.

>Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds.

This is just doing it wrong. State should change in response to user inputs. Ultimately, React is f(newState) => UI. If that function isn't pure you're gonna have a bad time. It's hard to blame anyone though. The docs suck and most of the tutorials you find get it wrong one way or another.

That said, there's kind of a reason why functional programming isn't more popular. It can be hard to grok and there can be a significant performance overhead. There's also a reason why this sort of implicit programming isn't as popular as imperative style. It's hard to predict what the implicit behavior is and footguns abound.

React had some obvious red flags; it seemed unwise to re-render entire components each time and regenerate the DOM instead of trying to work with it; it's a hack. It's not difficult to think of scenarios were it fails; for example think of what happens to an element's scroll bar after it has been re-rendered from scratch; it resets... Yet people kept coming up with workaround after workaround to all these kinds of issues. If they had tried PolymerJS (which was going for a native Web Components approach and interfaced nicely with the DOM instead of bypassing it), they would have questioned React's merits. When the useEffects hook was introduced in React, to me, that was a vindication of Polymer's stance (which it had figured out years earlier) that you couldn't completely pretend that DOM elements don't exist, yet React's solution was not as elegant as Polymer's as it was tacked on as an afterthought rather than as a carefully thought out design decision.

Nowadays, with native Web Components (HTMLElement) in most browsers, I don't see why people would still start projects with React, especially given the massive number of dependencies it typically introduces and how often they keep changing stuff and breaking compatibility.

They promised a simple component library which would be the answer to our prayers. What we got instead is a 7 year religious pilgrimage which involved a million developers simultaneously trying to make sense of it; attempting to discover its true form by inventing abstraction upon abstraction and growing increasingly fanatical as it devolved into a wicked monstrosity which should have brought the wiser among us to our knees, begging for JQuery.

We can agree that state management is complex, no matter how it’s done. If you disagree, cool go build a database.

Of all the complexities around state management, the one squarely placed at the top for me is: time.

State is a variable you care about, that will change over time.

Signals and Hooks/Effects present two very different approaches to the problem.

They both require updating your mental model, and they both have specialised tooling.

Myself, I’ve never fully grokked observables/signals—particularly in relation to a UI. They shift complexity into a location that I think makes them harder to reason about.

I did take to the React approach with Components and hooks. And in my experience so did many others.

I disagree with the article saying all frameworks must have signals, and I appreciate the React core team holding their ground on that.

It’s healthy for the ecosystem to have frameworks built on different ideas, otherwise why build a new framework?

But React, if you added signals I think you would warp it’s entire foundational paradigm.

You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables!

You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you use and you should go back to UI development 101.

Bottom line: if you write clean code and are aware exactly of what your local state / redux variables are (or whatever state management you are using), you should never have a problem with too many rerenders. I've been writing React for 6+ years now and have NEVER had to reach for useMemo or useCallback.

The quickest obstacle you’ll run into as someone new to React will be something like this

function MyComponent() {

  const [num, setNumber] = useState(42);

  // infinite loop
  setNumber(n => n + 1);

  return <div>{num}</div>

Trying to make state updates at the top level of a component will result in an infinite loop.

```

I've taught React to dozens of people without ever seeing someone try this. A render function is an idempotent function that produces UI for a given state, and it's called every time the state changes. What are you, semantically, trying to do by updating state midway through a render function? This isn't a footgun, this is the author picking up a screwdriver and going "I wonder what happens if I press it against my eyeball"

I... isn't it? Isn't this like the first thing in the hooks introductory material? If you don't find this, yeah, hooks are gonna be a bad time.

For the longest time React was kind of in denial to a large degree about what they were. They called themselves a View library. Hooks have definitely noticeably changed that relationship, & how people integrate app state with React, but the problem here of updating hasn't really changed all that much.

It's not a new thing either. A lot of the initial resistance to React & the VDOM was that it felt like unnecessary work. Because so many frameworks at the time were working towards two-way data-binding systems, which aren't necessarily but were often associated with with smaller, precise DOM updates. HP/LG's WebOS's underlying Enyo project was one high profile would be effort here.

Signals have definitely been a good re-grouping point, for reconsidering what the shape of things might look like, for trying to do a better job.

I'm a bit surprised we're still operating so much at a library level regarding reactive systems/signals. JavaScript objects have quite a lot of flexibility already, and the addition of Proxies added a lot of capabilities. Faint/distanct memory, but I think Proxies were justification for killing Object.observe[1]: now users could do whatever they wanted, so we no longer needed a JS native way to see objects change. Yet, we're still very library based, rather than trying to make objects themselves better, more reactable.

[1] http://web.archive.org/web/20200218195131/https://developer....

The problem each of them tried to solve, and continue to try to solve is purely lexical in the end. It's about writing things differently. Creating abstractions (terms) beyond what the underlying language/platform allows you to do.

And this is not a bad thing. The solution really is to create your own language so you can express the problem you are solving in the terms of the problem and not the underlying language/platform/hardware.

And then I sigh again... aah but if only Common Lisp and it's macros were the underlying platform.

Being able to use such similar concepts/knowledge for both web and mobile, with strong results in both places, that’s something React is uniquely good at (AFAIK), and a huge reason to choose it IMO.

There are not many examples of such code bases. Maybe numerical algebra libraries come close.

Reading through the comments it seems that providing (fairly basic by now) UI functionality on cross-platform basis has not matured to the point of providing a stable paradigm.

Given how many people and for how long have been banging on this problem it feels a bit strange.

Surely people can find better use for their time and energy than churning through half-baked frameworks?

I don't understand this quote from Tanner. Aren't React hooks, like, the only way to tell a function React component (while inside of it) to re-render? And if you look at the code of, say, the useBaseQuery hook of tanstack-query, you will indeed find React's native hooks being used there [0].

0 - https://github.com/TanStack/query/blob/main/packages/react-q...

At the end of the day, they approach the problem from two different directions, solve issues in two different ways, and end up with two different sets of challenges in terms of what's easy and what's hard in them.

I've definitely written React UIs that would be easier in Angular. But I've also crashed Angular performance through the floor trying to wire up a table display with Angular update hooks. Angular makes it easier to hide state-update dependencies in a way that causes really bad thrashing to reach steady state, which I've (anecdotally, generally) found harder to do in React because doing it in React involves writing a lot more code and a lot more cross-state dependencies.

Most of the footguns listed in this article are things you obviously shouldn't want to do because they're not React-y.

It's a pretty major rant, without putting forward an alternative.

The only viable alternative for me personally is VueJS and that's not my cup of tea either.

I like React. It makes sense mostly.

Is React perfect? No.

Do I like React's recent transition to focus server side? No.

But the problems it addresses are tough to solve.

Show me a better solution and convince me its tangibly better than React.

I think React creates needless complexity. The software I write is complex by it's nature, I do not need the software I create my application within to exponentially increase that complexity. React does not just let one write code and create one's application, React dictates how the code is written, and if that does not fit with one's application structure you must change it. And React developers cannot wrap their heads around anything other than React's dictated way to write React, so... they are useless.

So, what do I use: nothing. I just write html/css with direct DOM access via js, very minimally. Dicking around with the web page is the least priority of the applications I write, and the freedom to create the application structure as the purpose of the application dictates is far more important to my clients. Plus, I do not write consumer click bait vehicle software, I write software for people to accomplish things, typically complex things of the nature an engineer, designer, or architect would use.

I've gotten to the point where I think frontend code should just be modeled as state machines from the start. I like XState but you can use reducers too if you like.

Back with components, it was trivial to compare old and new values and change the state based on that.

No affiliation, happy user for years.

https://github.com/reagent-project/reagent

I'm glad others have found value in the evolution of react, but it always felt like watching a tragedy from the outside as the newest Abramov idea seeped through the ecosystem.

My own impression is that the core model of state and rerendering is actually quite nice and intuitive, though often explained a bit wrong. The part that makes it complex and confusing are things like callbacks, which can trigger lots of unnecessary rerendering and force quite some boilerplate if you want to avoid that. If you can remove all the stuff around trying to avoid rerendering unnecessarily, React would be a lot simpler.

I also think that people are too quick to use the wrong tools for managing state in React, e.g. Context to avoid a bit of prop drilling.

React enables v=f(s) by making DOM updates faster. v=f(s) was always a good idea, but before vDOM, replacing the HTML of the page on every little state change was too much for the browser.

- Now you describe your views as pure functions of their inputs and stop caring about them, React cares about them. You know that with the right s, the right v will follow.

- You need to care and manage your app's state carefully, yes, and everything goes in there. Fortunately, patterns and frameworks like Redux make it releatively straightforward to do this.

You can still make a mess, sure, and make mistakes, etc, of course. No silver bullet. But you can now deal with those two separately. If you start fetching data from your components directly you're back in jQuery hell with extra steps.

I may be wrong here, or it could be my age showing, but I feel like explicit UI systems like that might be more verbose, but I find them more accessible to dive into and less "magic".

I'm totally lost and baffled by everyone's enthusiasm for these increasingly arcane and complex abstractions. I suppose they are necessities that arise when you reach a scale that I have not yet encountered (I work on small to medium sized teams of a dozen or dozens rather than hundreds of programmers).

https://reagent-project.github.io/

I have also been able to consistently hire absolute greenhorns right out of tech bootcamps with zero formal computer science training and they were able to build features that made our company real money and push to production within the first two weeks. React can't be that bad.

Now that we threw out react-hook-forms (Remix does it all fine with default form APIs), Apollo (don't need their caching any more, so just sending plain GQL requests via fetch does the job), Redux (Context API is just fine), emotion (TailwindCSS is so so so so so much better)... our Remix codebase is basically pure HTML and Tailwind's css classes. It's a bliss.

> Humans have a cognitive bias: "what is focal is presumed causal".

> Political leaders know this. They like presenting good news themselves because they like to be "seen" as causal of good stuff, but they'll get a press secretary to deliver bad news. Movie directors know how to use this when framing their protagonists within the story.

> Unfortunately, the React team have lost themselves in this bias. They keep trying to make the most focal part of the system (components) also be the causal part. Please stop doing that! It is a mistake. Events are what's causal - they embody the user's intent.

> Just to be clear, I love React. What an utterly brilliant idea and great execution. I'm deeply grateful because, wow!, did it change things. It is just that I preferred React when it was only trying to be the V part of MVC. Everything since has been downhill.

[0]: https://day8.github.io/re-frame/FAQs/LoadOnMount/#why-this-d...

This line however "It is not obvious that your component re-renders on state updates." is kinda strange, maybe it's not obvious if you didn't read any documentation or tutorial?

also "You could build your own framework in an hour using reactive primitives [...]" is the same as when people say "just make your own sorting algoritm", yeah sure you can get the exact behaviour you want, but come on.

I started out in these sort of frameworks doing Angular 1 in 2013. Did a lot more Angular 1 projects in those years, and really got to know the intricacies of the framework. Was ready to switch to Angular 2, but instead I ended up doing some native JS web components, a little React, then some Vue, and now some serious React.

I've got to say, I liked the little React a lot more than the serious React. All those useEffects everywhere don't make the code any more readable. There's layers upon layers upon layers of components and abstractions and layers in between. It comes across as less organised than my old Angular 1 or Vue code did, though that's probably also due to the size of the code.

Anyway, I'm not being held hostage by anyone. Next project I hope to be doing something in Svelte, but maybe I'll end up doing something completely different. Maybe some Kotlin? I still haven't used that.

On the other hand, other less experienced developers didn't like Elm so much because React allows you to write your app with fewer lines of code. The article from this discussion explains well that React (especially with hooks) hides complexity, which bites people later. At that time, it is perhaps too late to switch to something else.

Needless to say, I haven't been able to convince any other employer to use Elm, and then I see issues popping out all the time that would never happen with it. Such a waste, just because people like shiny toys and just follow what others around them are doing without thinking too much.

[1] https://elm-lang.org/ [2] https://redux.js.org/understanding/history-and-design/prior-...

But I think the criticism here is a bit sharper and more pointed than that. The author isn’t expecting Reach to do something for which it was never intended, I think. Instead, they’re saying that the abstractions (hooks in particular) that have evolved over time expose unhelpful interfaces that either conceals too much information, encourage poor patterns that lead to bugs, inefficiencies, etc.

In other words, the criticism isn’t of React’s explicit decision to offload responsibility outside the scope of outputting UI, but rather that it’s evolved to make handling of those responsibilities more challenging.

I think that’s a bit more serious than the former critics and worth at least considering. For my part, I’ve found little substantive advantage to hooks and do think they hide a lot of bugs by making implicit things that should probably be (and, once upon a time, were) more explicit.

Most of this article is a rant against the react hooks project, not React itself.

1. I’m not sure what they have in common with each other. What exactly is a React hook. Nearly every hook is its own thing, with its own purpose, use, etc. With the new “use” hook, even the original hooks rules don’t apply anymore.

2. Related to the above, every hook is an entirely new concept. Learning react you would think once you learn “hooks” you will be able to understand basically what they did. Much like once I learn “classes” or “functions” I can figure out what they are. But every hook is its own concept, with its own rules, and gotchas, etc. Sometimes I wonder if the reason they’re called hooks is to present them as a single Concept, otherwise it would be too obvious that React replaced a few concepts, state, and component lifecycle, with about 3-5 concepts in the library in the early versions, and many more now, with an infinite possibility of concepts through custom hooks.

3. No one in the React world seems to have a clear mental model of what hooks are. useEffect is the most egregious here, but the name (and the original React docs) indicated it was for side-effects. But then it’s also used for lifecycle management. Finally, it appears that now the React devs have started pushing the idea that it’s to keep “components in sync with an external system”. And useEffect is probably the most used hook outside useState.

To be fair, usually descriptions of concepts can change with time. But with useEffect it’s not just the description that’s changing. It’s the entire mental model, which makes it seem that the React devs themselves are not clear what useEffect is supposed to be.

Fundamentally, hooks seem to be a bunch of ad-hoc solutions that React devs use to solve specific problems they notice in the wild. But there doesn’t appear to be any fundamental consistency to what they really are.

The first example of UI frameworks is always the `counter`, but it's always the least realistic scenario you encounter. Almost every app involves retrieving state over the network, sharing state in multiple places in the app, and how this state is CRUDed.

The reality is that all state is very interconnected.

Ideally you want fine-grained reactivity for every rendered UI element, that ultimately reacts to the changes in a database in the cloud.

And every piece of state should ideally be persisted. Even things like dropdown menus and their state.

The simple solution to all this is to store all state/data in a single database on the client. Every time you render something from the database, a component should have its own "view model". And this view model should react to changes in the database.

This "view model" also shouldn't be hidden inside components. There should be one place where you can view all the view models throughout your code. And see the interconnectedness. In a visual way too.

Maybe we went off-track when we started to merge the view/model/controller in the same file. We create hierachies of views, and then they need to get their data from this view hierarhcy. But instead they should be getting their data from a central database in as few transformations as possible.

The mistake people make is trying to make components isolated and decoupled from the rest of the app as a principle. It sounds nice, in that when you work on a single component, you only have to worry about what props are being passed to it. What makes apps complex though is data transformations. Ideally you want data to be as close in shape to the underlying dataset as possible. Otherwise caching/memoizing becomes very difficult, and this is usually the cause of many performance issues.

I wonder how many of the issues people have with React are due to it not being built on a state management library - like Vue is, and Mercury was.

The rendering is whatever. Templates, JSX, it doesn't really matter. Mercury used hyperscript and we got by just fine. But state management is critical, and React seems to leave it completely up to you.

Vue added a hooks-like API. While I haven't used it in anger, I've toyed with it. And it sidesteps some of the weird React hooks caveats... because of Vue's reactivity system. Huh.

*With a brief interlude using the original Angular, which I did not understand then and still do not understand looking back from today.

> It’s just abstractly funny to watch the ecosystem of a UI renderer work so tirelessly to keep using it while avoiding every part of it.

I would call this concept noodle. Because when there's a lot of them you get back your tasty spaghetti. The whole reason for React was avoiding it whenever possible.

I use sometimes, but for the most part is overused feature.

I think thats a symptom of a problem with the front end community, people get too attached to the new thing and try to make it the standard instead of building something stable and concise.

Im tired to having to rewrite a code because one library that I had to upgrade decided to migrate to the "new thing"

Why the modern obsession with hiding the underlying state machine with callbacks? To prevent devs from seeing the bigger picture?

I'm lucky that I am an independent developer so I can choose to use Solid JS in my projects.

React has so many gotchas and they keep changing the 'best practices' I can't believe people still stick with it.

Does anyone have a source?

In game dev you run millions or even billions of computations 60 times a second. If running toTitleCase three times every key stroke is an example of a compounding performance problem in React then surely the problem must lie deeper.

POST/Redirect is beautiful. It’s fast. It’s simple. It’s low maintenance.

> What would framework-integrated fine-grained reactivity look like? Probably something like Solid.js

It would look like JavaFX which has had this exact approach since it launched over 10 years ago as well as a large library of observable operators and collections complete with delta events, the ability to define components with a "shadow DOM", with custom CSS properties, using both JSX-like widget-oriented markup and code, and a whole heap of other things the web community has since slowly rediscovered. Here's the high level observable operators API (there is a lower level one that lets you define custom operators):

https://openjfx.io/javadoc/19/javafx.base/javafx/beans/bindi...

And here's the author's Solid.js example in Kotlin with FX:

  class Counter : Label() {
    private val count = SimpleIntegerProperty(0)
    init {
      textProperty().bind(concat("Counter: ", count))
      timer(period = 1000L) { runLater { count.value++ } }
    }
  }

So not much different, but it demonstrates how the text property of the label is bound to a dynamically computed string which is in turn bound to an observable number. When the timer fires, the count increases and the label is recomputed. Everything is done that way so layout computations, for example, won't run unless the size of the label changes. And that's it - no need for VDOMs or prop drilling or state memoization or any of these other performance hacks.

At some point you'll observe that this seems a lot like "reactive programming" as used on the server side, and then might want to explore a library like ReactFX which connects these two worlds together.

https://github.com/TomasMikula/ReactFX

There are some other nice features in this type of toolkit that the web community seems to be heading towards. I'd be willing to bet a lot that at some point they'll even reinvent inheritance under a new name, because being able to write code that's generic over component trees is really pretty useful. The hooks/functions model totally wrecks that and has led to this explosion of "design systems" (otherwise known as themes that bundle half a widget toolkit), none of which interoperate properly or can be coded against in an abstracted manner.

None of this is to say that FX is perfect or that React/SolidJS etc are the wrong tools to use. You can run FX apps in a browser using a form of server side rendering - check out https://www.jpro.one to see a fully crawlable website that's actually implemented using JavaFX on the server with no frontend/backend split existing at all. But it only works well if you don't have a fast and reliable server connection, plus a server with plenty of RAM and CPU. Alas browsers pull all sorts of mean tricks to keep people locked inside the HTML5 sandbox so JS frameworks aren't going anywhere, but it would be nice if that community spread its wings a bit and looked at prior art from outside their language. GUIs are old and the challenges involved in them aren't new, and from the outside it looks suspiciously like there is no real progress being made here, only wheel spinning.

[1] https://github.com/cheatcode/joystick

It seems like the framework culture is driven by the search for a silver bullet that makes problems go away. But each solution to a problem always comes with its own set of problems, only these problems are initially unknown. So you trade a set of known problems for a set of unknown ones.

It is possible that these new problems are lesser problems, but this is hard to verify upfront, and the nature of being unknown makes it a lot harder to deal with them preemptively.

So anyway, you have your framework, you have used it for a while, and you have learned about the previously unknown problems that it causes. You could rejoice that you now have this knowledge, and therefore have a reasonable shot at working around the problems. But instead you ditch your imperfect framework and search for a new one, beginning the cycle anew.