Live data from Hacker News

React 19 Breaks Async Composability

github.com

81–90 of 114 posts

Re: React 19 Breaks Async Composability

#81

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

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.

Re: React 19 Breaks Async Composability

#82
post #79

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.

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?

Well call me a heathen, but I've never even considered React. Instead I always generate HTML server side and spruce it up using a little JavaScript if necessary (I even use jQuery sometimes). It's reliable, works fast, easy to debug, requires little maintenance, doesn't require a build chain of >100K files of several hundreds of megabytes.

Of course I'm open to the possibility that I'm Doing It Wrong™.

Re: React 19 Breaks Async Composability

#83
post #48

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…

React since 17 feels like coding with LLMs: it had a bug, they asked ChatGPT to fix it, it addes more bugs, they asked ChatGPT to fix all of them and now we have a useless piece of software completely unrelated with the initial solution

Re: React 19 Breaks Async Composability

#84
post #37

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.

The backward incompatibility story https://www.php.net/manual/en/migration70.incompatible.php is not empty

Re: React 19 Breaks Async Composability

#85

Earlier quoted context omitted.

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

I don't know who decided it was right to flag you into oblivion, but GraphQL is unrelated to this.

You don't always have full control over the backend. You may depend on another team, or maybe even access a public API. React was (and still is) good at that, but with suspense, it's as if they forgot that a Web-App may want to do more than just "take stuff from server and show".

Re: React 19 Breaks Async Composability

#86

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

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.

I'm old, but I still think that knockout.js is the bee's knees.

Re: React 19 Breaks Async Composability

#87
post #37

Earlier quoted context omitted.

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

The backward incompatibility story https://www.php.net/manual/en/migration70.incompatible.php is not empty

In 10+ years of professional PHP development, the only time I've ever had to fix a codebase while updating the PHP version was when mcrypt was deprecated, and it was only around half an hour of work to replace it with a modern equivalent, including the time to re-encrypt the data.

Meanwhile, I've had the misfortune of inheriting a React application that would no longer build a mere six months after the original developer left the company. I've come to loath working on React projects due to the insane amount of library and tooling churn in that ecosystem.

Re: React 19 Breaks Async Composability

#88

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…

Sorry to ask, but what classified as AAA site?

https://aaa.com/ comes to mind...

Re: React 19 Breaks Async Composability

#89

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

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.

Svelte and solid are nice alternatives.

Re: React 19 Breaks Async Composability

#90
post #4

Earlier quoted context omitted.

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

Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week? I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current j…

I'm one of "those".

I'm using bun now, but I was on pnpm for a while.

Post reply on HN