React 19 Breaks Async Composability

[danfritz]

Ha great we finally arrive at the "Next.js React features" which basically forces everyone to use Next.js or an additional framework on top of React which now have to play catchup with whatever react - next.js think is "best" (for Vercels wallet). Expected outcome if half or the react core team is a Vercel employee.

Kinda new this day was coming, sad to see it actually happen

[meiraleal]

I'm not sure yet if I'm happy or sad with Vercel's destruction of React. After 10 years of React, I think imploding it from inside was the only way React could lose its lead. They achieved it!

Even tho we don't have a clear alternative yet.

[harrisi]

This is why I'm sad about Svelte core being maintained by Vercel employees as well. They have definitely positioned themselves well to be in control of a lot of modern web development and deployment, but it makes me not want to use Svelte, SvelteKit, React, or Next.

Vue is the only main independent framework that exists now, apart from jQuery.

[mrkeen]

> when navigating to a new screen, it's better to show a loading state as soon as you can (often a skeleton UI), rather than delay the transition.

In a better language, this would be the programmers choice on a case-by-case basis, with no need for the higher-ups to break or fix everyone's behaviour at once.

Either return a Page(Future(Components)) or a Future(Page(Components)).

[tomgp]

"Navigating to a new screen" is such a basic behaviour of the web the idea that we need to rely on a framework to manage this in some way is absolutely insane. At this point the complexity that React imposes on developers is out of all proportion to the benefits that it provides.

Yes there are cases where React is exactly what's needed but when each new version introduces new "best practices" based on how "bullish" Meta's developers feel about a given approach it removes a crucial advantage that helped these libraries become popular i.e. that it's easy to onboard new people on to a project because thewre's a consistent approach across code bases. Right now there's not a consistent approach across 2 or 3 years of React releases and that's before we come to the torrent of metaframeowrks designed to smooth over inconsitencies and deficiencies (state managment! styling!).

I don't know what the answer to this is but having spent a good portion of the last 7 years or so on and off React projects I would advise anyone to think carefully before investing time and /or money in the ecosystem. On balance the benefits aren't worth it the large majority of cases.

note: i've used library and framework carelessly and interchangably here, React has historically been keen to market itself as a library i.e. something you dip into when needed but in practice it bends the whole dev process around it so I feel framework is more apt

[Varriount]

Or better yet, just... Navigate to a new (real) web page? Maybe passing some state via URL parameters? At least then the back button has a reasonable chance of working correctly.

[nikanj]

I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.

[wtf242]

It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.

no thanks. I will stick with Rails.

[rimliu]

I have a harsher take, 95% where react is used it is used without the need.

[rjh29]

This used to be confined to web dev, and my backend job was happily tinkering away at 15+ year old code written in stable languages and frameworks, deployed via RPM/Puppet. But we took on too many graduates and now suddenly everything is being rewritten in new languages and we have an insane amount of Kubernetes config attached to everything.

[ibash]

Class components was the last good react idea.

[mouzogu]

"move fast and break things" as zuckerborg himself said

most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated"

effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now

[anonzzzies]

Terrible shitshow. Web dev is all broken and horrible. Well at least the popular stuff is. No idea why anyone uses this outside resume building.

[sir_pepe]

Fortunately it is very easy to opt out of all of this. Nothing stops you from having a backed deliver HTML and then sprinkle some basic JS and CSS on top. In theory at least, in practice everybody's brain has been smashed to bits by repeatedly colliding with the hype train. But the old approaches still work, even better than in the old days (thanks to improvements to all the relevant standards).

[hi-v-rocknroll]

It's a jobs program. Maximize breakage and churn for everyone while disrespecting compatibility and stability.

[pragmatic]

There’s hope.

Vanilla js with type annotations via jsdoc and a build less setup works amazingly well now.

I’m rebuilding our companies data viz with this set up as the “glue” between apis and charts.

Throw in web components and for some use cases I think you really don’t need react, etc.

[wordofx]

HTMX is the way forward.

[sergioisidoro]

From the discussion:

> My favorite way to do data fetching is as close to the place where I am using the data. React made it possible up until this change.

Well, yes, but we are nowadays in a situation where every component interacts directly with the state, or makes calls to the API (eg with the overuse of query), going against one of the architecture principles of react. It's like we're not building components, we're building component sized micro-ui.

[sensanaty]

As a React dev at $DAYJOB, how React remains at the top despite the existence of infinitely better alternatives like Vue or Svelte will forever be baffling to me

[shepherdjerred]

What do you like about Vue? I use Vue at work and yearn for React (though, I haven't written much React since the shift to hooks).

[azangru]

I thought these two short video demos by Ryan Florence of how this problem is mitigated in the upcoming react router 7 would be relevant for this topic.

- https://x.com/ryanflorence/status/1801383836250739057

- https://x.com/ryanflorence/status/1801388170891903252

[SebastianKra]

This looks nice for a single query, but, like basically all the previous discussion around this, he skips over the case where you might need to kickoff fetching of dependent data.

So in your loader, you would have to fetch the data, transform it, extract a key for the second query and then prefetch that.

...and in your component you would have to do the exact thing again, except you probably have to write the transformation logic twice, because hooks don't compose well with promises.

Of course you might say that dependent queries are a bad practice anyways, but in the real world this happens quite a lot.

To be clear, Suspense was always bad at this. To my knowledge, there was never a good way to combine SWR and lazy fetching with Suspense. You may or may not have been lucky, if your queries mapped well to the component tree.

I would like to see a solution from either React-Router or Tanstack-Query, but both of them prefer discussing the problem away.

[jenadine]

What does that mean? (for someone not familiar with React)

[orangepanda]

Nothing functional breaks because of this. Waterfall requests, which already had bad ux, have worse ux now.

[crooked-v]

It makes anything that does lazy loading in parallel noticeably worse by forcing waterfall-only loading, in order to make rendering and management of loading states slightly better.

[EugeneOZ]

is it something similar to Deferable Views in Angular? https://angular.dev/guide/defer#overview