zlacker

They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly.

It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0].

To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each.

[0] https://saewitz.com/server-components-give-you-optionality

>>switz+(OP)
But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.

>>ptx+Fa
Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.

You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.

>>switz+(OP)
Just because something is made possible and you can do it doesn't mean you should!

The criticism is that by allowing you to do something you shouldn't, there isn't any benefit to be had, even if that system allows you to do something you couldn't before.

>>switz+(OP)
It also gives you a 10 cve