[sktrdie]

Will this whole idea of writing more server-side logic pay off?

I'm not sure. It felt like we were moving towards dumb backends that sync automatically towards frontends that would contain most logic. Things like https://localfirstweb.dev/ or https://electric-sql.com/ felt like the future

Writing more server code (as quoting/react-server-components are suggesting) will increase the surface area where errors can occur. Limiting that to either just the server/client feels like a much saner approach

[danabramov]

That's a good question! I'll maybe post some time about that. I don't think sync engines are "the future" although they have their uses. But if you care about large-scale aggregation, private data with sophisticated permission models, aggregation across private data, feeds, and such, server/client is a much more powerful model. For example, I don't think you can implement something like Twitter in a pure peer-to-peer fashion without compromising on functionality a lot.

[qudat]

> I don't think sync engines are "the future" although they have their uses

I think the same argument applies to RSC. For many use cases, it doesn't make sense. Many organizations and projects do not need SEO or server code specifically for their FE. If the organization has committed to an API service in order to support a range of clients then RSC/react server framework is "pure overhead."

As someone who has been building with React for a decade, RSC was the moment where I felt the complexity vastly outweighed the benefit. I'm in a position where I can argue that SPAs are dramatically simpler to implement compared to RSC/nextjs, which I think would be surprising to outsiders who bemoan SPAs as complex.

I find the "preload then rehydrate" data synchronization model simpler to understand and can turn even the slowest APIs into an app that feels instant: https://starfx.bower.sh/learn#data-strategy-preload-then-ref...