server-components

Sorry about your experience. > Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. Is this with a fresh Next.js project of after you've added user code? If the former and there's a GitHub issue, let me know and we can take a look. Thank you. > Also, the “fix” for many issues was to throw “use client” at the top of problem files. The Server Components model is still really new. It'll take some time for the ecosystem to evolve here. Here's a good post if you want to learn more: https://github.com/reactwg/server-components/discussions/5

Dan, you can't deny that most (if not all) the comms from both the React team and Vercel make it obvious that Vercel is not only first-moving on RSC but working intimately with the React team to both vet the implementation and I'm sure offer (opinionated) advice on tweaks/direction. Also, links to packages with 5 line READMEs and no comments/documentation in the code might as well be called blackboxed. Yes, its open source but that's pretty much it. John or Jane Doe will have to deconstruct and/or assume the team's intention by combing through your links, https://github.com/reactwg/server-components/discussions/5 and the (light) documentation from Vercel on how all this stuff really works. All I'm asking for is clarity and the ability to potentially create my own implementation rather than watch the "big guys" (read: frameworks) get the a

The design you're suggesting doesn't work because it would cause server/client waterfalls everywhere, which goes against the entire purpose of the architecture. The data flows in one direction: from the server to the client. It's just physics — your server is where the data is. You're trying to move it to the client. So the code that needs to run first is the server code. This is why the data flow starts at the server. You can't fix this by changing how opting in works, or some other API design workaround. What you're fighting with is the arrow of time. As for the terminology, I agree it is confusing, but I have not seen a better suggestion yet. I shared our reasoning here (https://github.com/reactwg/server-components/discussions/4), hope it's helpful.

While this may not be satisfying, I tried to write a response to a similar question here: https://github.com/reactwg/server-components/discussions/4

Do you have terms that you prefer (to Server/Client split)? I agree they're confusing but I haven't seen any proposal that would address the issues with them without introducing other issues. I've tried to explain our current terminology here: https://github.com/reactwg/server-components/discussions/4