Hacker News Reader

Comment by wild_egg | Hacker News Reader

Who said you were selling something?

My point is that the entire approach is architecturally far more complex than is suitable for the vast majority of projects. You have influence and people will make real world decisions to choose unnecessary complexity because of this article.

Why do 150 lines when 10 lines of PHP is functionally equivalent to the user? The user doesn't care about your execution model. They just want some information or to submit a form. Adopting an RSC-like technology makes development more complicated and take longer.

If you're building Figma or something then sure, go nuts with the complicated things. The tradeoff probably makes sense.

For the other 99% of us, this model just gets in the way.

View on HN

The execution model enables more powerful composition (reusable components whose functionality spans both client and server) which hopefully helps people make things people want faster (the story of our industry). Sam gave this argument a wonderful treatment in https://www.youtube.com/watch?v=9CN9RCzznZc, I don’t think I can make as compelling a case in a comment. But he fully represents my viewpoint on why. If you’re genuinely interested then do check it out.

One of the biggest problems with mixing client and server code like this together is coupling which is one of the reasons that client-server architecture was created to avoid.

I watched the video, and it didn't feel compelling honestly, backend frameworks like symfony have ways to compose client and server side code for years.

There are many ways to mix and match client(js) and server (php) in a composable way without react. Components can be created on the server side as well (mixing html+js+php). Only thing lacking is DX and type checking.

Most other solutions are not composable to the same extent. It’s not enough to be able to mix client/server (although that’s a start). It’s more about it going all the way — for example, the state of the client parts is preserved on refreshes of the server parts around them, the same components can be reused on either side depending on whether you want them to be state-driven or data-driven, state changes are predictably instant, you can stay within the same paradigm while moving code between highly interactive and fully data-driven (no awkward moving stuff “between PHP and JS” when something needs to be “more dynamic” and back when it needs some server-only feature), ability to send closures over the server to the client and back (lets you essentially .bind server actions over the network), all of this is integrated end-to-end (a client button can know precisely how long to display an indicator while the server is data fetching next page and the next client code and CSS are loading), and of course all of this being fully composable (you can nest server stuff into client stuff into server stuff into client stuff and they all retain state and refresh as you would expect).

If you don’t see what’s new about this I encourage you to look deeper because this definitely isn’t what backend frameworks have been doing for years so you are missing something.

I feel like it's a great bellwether that react has jump shipped as a viable way to build applications if the mindshare of maintainers/core devs/influencers are pushing in this direction.

Reply on news.ycombinator.com