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

51–60 of 114 posts

Re: React 19 Breaks Async Composability

#51

Post by Varriount »

mrkeen wrote: post #24

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

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.

Re: React 19 Breaks Async Composability

#52

Post by Varriount »

tmountain wrote: post #28
rimliu wrote: post #9

Earlier quoted context omitted.

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

Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?

React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page).

You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a problem using the back button or ctrl-clicking links while navigating GitHub - which is not something I can say of most other React and heavy-js websites.

Re: React 19 Breaks Async Composability

#53

Post by 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

Re: React 19 Breaks Async Composability

#54

Post by mrkeen »

Varriount wrote: post #51
mrkeen wrote: post #24

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

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.

I believe I was only talking about a single page load.

Instead of a choice between progressively loading in /page-a or waiting for /page-a to fully load before showing it, just direct the user to /page-b instead?

Re: React 19 Breaks Async Composability

#55

Post by 000ooo000 »

rimliu wrote: post #9
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.

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

The minimum technology required to solve a problem isn't always the same technology that a team has experience with, has existing projects/code in, can readily hire for, etc. Nor is it necessarily the same technology capable of solving future problems. Besides, some people just like the mental model of some tools and enjoy working in that way. The idea that we have to pick the minimum tooling every single time usually seems like flawed thinking based on that out-of-context Tim Berners-Lee quote.

Re: React 19 Breaks Async Composability

#56

Post by 000ooo000 »

Varriount wrote: post #52
tmountain wrote: post #28

Earlier quoted context omitted.

Prior to React, most developers just invented a strategy for structuring code on the client side. What’s your preferred alternative?

React isn't a way of structuring code though. It's a whole (huge) framework dedicating to making web apps/pages. And most of the time it seems to be used to replicate functionality that the browser can already natively do (for example, navigating to another page). You want a good example of how a non-react website and its code might be structured, look at GitHub. At least from a user perspective, I've never had a pro…

>replicate functionality that the browser can already natively do

That's.. basically every lib. Welcome to abstractions.

Re: React 19 Breaks Async Composability

#57

Post by cageface »

thomasfromcdnjs wrote: post #47
cageface wrote: post #36

Earlier quoted context omitted.

Hooks make it easy to compose logic and effects. The actual implementation has some serious warts but the fundamental idea is great. The React compiler looks like it will eliminate a lot of the error prone manual dependency tracking that usually trips people up with hooks.

I didn't like hooks from the get go because it was the first time I found the automagical behavior that web dev was somewhat leaving behind starting to creep back in. It's insanely hard (nigh impossible?) to debug an aging app that has use useEffect's and useState's everywhere. (This wasn't the case with the class components (not suggesting that class components were the be and end all)) Now the Compiler sounds nice,…

I've seen a lot of JS frameworks come and go. Eventually they all become hard to work with as complexity accretes to address more use cases and keep performance up. The same is true of native frameworks. SwiftUI and Compose are great when you're just getting started but as soon as you start building complex apps things get hairy fast.

I think we still just haven't figured out how to build a UI toolkit that is both highly expressive to use and performant for complex UIs.

I think there are some really great ideas in hooks but it might take a new language built around them to make them truly ergonomic. The React compiler is a step in that direction.

Re: React 19 Breaks Async Composability

#58

Post by unconed »

nottorp wrote: post #45
crooked-v wrote: post #16

Earlier quoted context omitted.

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.

What does 'rendering' mean in non javascript terms? I have a feeling it means 'generate html' in english.

Recursively expanding components until you end up with nothing but HTML.

Re: React 19 Breaks Async Composability

#59

Post by kalleboo »

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.

I maintain a PHP codebase that dates back 15 years and I can count the breaking changes on one hand, and they were all tiny one-line changes

Re: React 19 Breaks Async Composability

#60

Post by rjh29 »

wordofx wrote: post #29
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.

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.

Post reply on HN