zlacker

>>rayhaa+(OP)
Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve?

What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering?

Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compiler, but instead of going the svelte route of handling the entire state, it only adds memoization?

If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic.

sorry for the rant.

>>halfli+yO
Totally agree. Chiming in as another React dev: I really regret the last few years of choices React has made. I don't want a React-integrated BFF layer, even on greenfield projects, hooks are awful and the whole thing just gets more awkward to solve tangentially related problems.

I really do want a good frontend framework that lets me expressively build and render dynamic frontend components, but it feels like 99% of React's development in the last few years has been just been creating churn and making that core frontend experience worse and worse. Hooks solve challenges around sharing component meta-functionality but then end up far worse for all other non-trivial cases, and it seems like RSC & concurrency just break things and add constraints instead of improving any part of my existing experience.

I guess this is cool if you're building mega-projects, but it makes React actively painful to use for anything smaller. I still use it every day, but as soon as I find a good off-ramp for my product (something similar, but simpler) I will take it. Moving towards Preact & signals currently seems like the best option for existing projects so far as I can tell.