Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React 19 Breaks Async Composability

github.com

Post reply on HN
Print view View original

71–80 of 114 posts

Re: React 19 Breaks Async Composability

#71

Post by lakomen »

creshal wrote: post #37
thibaut_barrere wrote: post #13

Earlier quoted context omitted.

In that regard, my experience has been the following churn scale: JavaScript churns more than Rails which churns more than Elixir/Phoenix. I believe this is caused by “how sound the fundamentals are” (technical debt in the language itself and its stdlib).

PHP devs meanwhile: You guys churn? For better or worse, you can take 10+ years old PHP code and it'll mostly just work.

My handcrafted legacy.c64g.com site made in 2005 still works with php8.3 (I see I have to renew the cert). I just had to switch from mysql to mysqli. However my Symfony sites had to be rewritten. Friends don't let friends code using Symfony. There was no upgrade path. Deprecated components with no replacement. I was so fed up with all the bullshit from 2010-2013 with the OO fetishism the "treat PHP like it's Java" from fresh students and graduates that I had to abandon it and switch to Go, which gave me peace of mind and a factor 100 performance boost.

Re: React 19 Breaks Async Composability

#72

Post by hi-v-rocknroll »

anonzzzies wrote: post #26

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.

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

Re: React 19 Breaks Async Composability

#73

Post by hi-v-rocknroll »

sir_pepe wrote: post #49
anonzzzies wrote: post #26

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.

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

Yep. And there's also Phoenix, Rails, and Htmx.

Re: React 19 Breaks Async Composability

#74

Post by SebastianKra »

azangru wrote: post #66

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

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.

Re: React 19 Breaks Async Composability

#75

Post by anonzzzies »

ht85 wrote: post #48
FriedrichN wrote: post #38

Earlier quoted context omitted.

Nothing is the way forward. It's programming, we make stuff that does stuff. Preferably with stuff that makes making stuff that does stuff easier and with stuff that will be supported for a long time. Maybe I'm too cynical, but whenever something is presented as some messianistic "way forward" I just think "ah yes, another way forward" but feel we're mostly moving laterally.

It is exactly that. We make stuff, problems arise, we make new stuff that does not suffer from said problems. Because everything is a trade-off, new stuff creates new problems. Those are the problems complainers complain about, ignorant of their history. The cycle then repeats. Maybe I am not cynical enough but doing easy things from the past is completely trivial and doing unimaginable things from the past is not th…

But it all suffers. We have been doing web dev for 30 years and it all works fine, fast and scalable. I am not sure what other people are so obsessed with but we don’t have these issues.

Re: React 19 Breaks Async Composability

#76

Post by lakomen »

varunnrao wrote: post #46
therealunreal wrote: post #31

Earlier quoted context omitted.

That's not it. The core issue is AAA sites vs apps. Let me explain. Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far. Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't re…

The issue really rears its head when we consider that most are in the second category but "modern" frameworks like Next.JS don't really cater to that market. I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead…

> want a frontend framework where I can build a foundation fairly quickly

Vue with Quasar has been that for me. And previously Vuex-orm, now Pinia-orm. With a RESTful backend.

However lately I've been using React because of a graphql backend (I hate graphql) and it's a relay type graphql and the frontend relay library only works with React.

React itself is pretty easy to pick up. But Relay is a pain in the ass. Fragments, @arguments, @argumentsdefinitions, the naming is a super pain in the ass. And it's even more of a pain with Typescript and doesn't work with Javascript. Reusing queries is not possible because of the naming requirements. You can't just have a PostFragment, no you need to have a MainPagePostsFragment and a ProfilePagePostFragment and a PostDetailPagePostFragment etc. But I digress.

React has been surprisingly cute so far. But I've also just been with it for 1 version only, 18. I could imagine switching to it because of the ecosystem and because most frontend jobs are React jobs. You can easily embed it into for instance static HTML files, unlike Angular or Vue, keyword easily.

Angular syntax is beautiful, but the framework is too time consuming. I have recreated a real-time forum, which took about 3 years to build with Angular in 2 weeks with Vue.

Bottom line, Vue, for me, is the most productive framework. Angular, Vue and React are all very similar. Svelte is a bit alien, because of its state management and kit being the nextjs equivalent, but apparently the fastest because of the compiler.

Re: React 19 Breaks Async Composability

#77

Post by lakomen »

5350-uiop-1130 wrote: post #25
nikanj wrote: post #2

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.

"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

And just what does a former PHP dev know about anything

Re: React 19 Breaks Async Composability

#78

Post by wordofx »

rjh29 wrote: post #60
wordofx wrote: post #29

Earlier quoted context omitted.

HTMX is the way forward.

This is just hype, just like with React years ago. There is no "one true way forward" Besides, HTMX is just HTML with JS on top which devs have been doing for literally 20 years. Rails had that kind of functionality in 2005 because I remember using it.

Yeah. We built junk like react because browsers sucked. Compute was expensive. We pushed processing to the client so someone else could pay for it.

Now we have gone full circle back to building web apps using something like htmx and no longer have a complicated mess to deal with. Render html on the server. Push it to the client.

Re: React 19 Breaks Async Composability

#79

Post by wordofx »

FriedrichN wrote: post #38
wordofx wrote: post #29

Earlier quoted context omitted.

HTMX is the way forward.

Nothing is the way forward. It's programming, we make stuff that does stuff. Preferably with stuff that makes making stuff that does stuff easier and with stuff that will be supported for a long time. Maybe I'm too cynical, but whenever something is presented as some messianistic "way forward" I just think "ah yes, another way forward" but feel we're mostly moving laterally.

So if we use stuff to make stuff easier why are people still trying to bang nails in with a piece of glass by using react when easy was using html/css/js made easier with htmx?

Re: React 19 Breaks Async Composability

#80

Post by ddaalluu2 »

SebastianKra wrote: post #74
azangru wrote: post #66

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

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 transfo…

Their solution is graphql, but I believe that the backend should have data for each component ready.

Example social network.

  /api/pagedata/FrontPage
returns a big ass query result, all posts with comments, comment count and reactions, all the data you would ever want in your front page.

  /api/pagedata/UserProfilePage
returns all the relevant data regarding the user's profile page.

Yes, if you change or extend a certain page, you will have to change the backend query. If you have 2 different teams for frontend and backend that's not straightforward, so there should be something where the frontend team writes the detailed expected json response and the backend team transforms that into queries. Or, let's be real, the queries get generated. One could even imagine a middleware that translates expected json to graphql queries.

Why not directly graphql? Because it's a major pain in the ass, because of relay. Graphql is Facebook. And instead of having the simple structure you can easily query, they added this stupid node relay structure which makes everything overly complicated.

I could imagine a Go backend or Rust where you have a comment with the expected JSON, and you type go generate and boom generated queries with search and pagination.

Post reply on HN