Live data from Hacker News

React 19 Breaks Async Composability

github.com

31–40 of 114 posts

Re: React 19 Breaks Async Composability

#31
post #4
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.

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

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 require server side rendering and their API backend can be anything.

In the latter model, you just host a bunch of static assets and point them to your API. No need for compute, everything is done client side (except API operations of course).

In the first model, you need to pay for rendering and it guides you into doing the API the same way. Closer to older PHP/ASP sites but on steroids.

This move caters to Next.js. IMO, as a lot of recent developments do.

Re: React 19 Breaks Async Composability

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

I've adopted the practice of avoiding libraries with major version > ~3. If you needed to re-design your API so many times, I don't trust your judgement enough to build on top of it. That said, I still use React and... it's at 19.x :'(

React jumped from v0.14 to v15.0, so in reality it's more like major version 4.3 right now.

Re: React 19 Breaks Async Composability

#33

Earlier quoted context omitted.

Functional Components are 10x easier and cleaner to use in React

Functional Components are not functional in the sense of functional programming. They are shared mutable state.

Function-based components. They have vaguely functional aspects but they are not functional indeed. I think most people say functional because "function-based" is too long.

Re: React 19 Breaks Async Composability

#35
post #29

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.

Is that a document markup language?

Maybe backend programming will become a lot simpler and easier and once they release XML2.

Re: React 19 Breaks Async Composability

#36

Earlier quoted context omitted.

You could already use functional components before. The main issue with React now is all these hooks and effects.

The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.

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.

Re: React 19 Breaks Async Composability

#37

Earlier quoted context omitted.

To be fair I’ve had similar issues with Rails

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.

Re: React 19 Breaks Async Composability

#38
post #29

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.

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.

Re: React 19 Breaks Async Composability

#39
post #3
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.

Class components was the last good react idea.

I miss class components!

(I know we _can_ use them still but it's hard to convince teams of people to stick with them and ignore what the docs say are best practices for the last five years.)

Re: React 19 Breaks Async Composability

#40
post #35
post #29

Earlier quoted context omitted.

HTMX is the way forward.

Is that a document markup language? Maybe backend programming will become a lot simpler and easier and once they release XML2.

It's essentially a small extension of HTML via JS, that allows all elements to fetch HTML from a server on events, and replace a target elements inner/outer html/append to it. From their page [1]:

motivation

    Why should only  &  be able to make HTTP requests?
    Why should only click & submit events trigger them?
    Why should only GET & POST methods be available?
    Why should you only be able to replace the entire screen?
By removing these constraints, htmx completes HTML as a hypertext

[1] https://htmx.org/

Post reply on HN