The most annoying problem for Zero's launch was what bug tracker to use. GitHub is way too slow, and Linear doesn't have public bugs or permissions – both required for OSS projects. This was driving me nuts, until I realized the only possible solution… ⏩ (link in reply)

I just do not see it. Take a look at the profile. Mainly the browser is just waiting for the server to return data. GitHub UI does a fairly good job of avoiding waterfalls. Presumably they do the one big request up front and then a bunch of little ones to get the main content out faster. But it looks to me that the _server_ is the problem here. Or to step back a bit, the problem is the architecture. It is fundamentally insane to go back to a central server on every user interaction. That is just not going to work ever to build a high performance UI.

“why is my next app incapable of > 300 requests per second?”

Here's how to better understand RSCs: RSCs are two sets of tradeoff, a technical and an architectural. Yes "tradeoff", not "benefit". It might benefit your use case, but it might also be disadvantage. 1 - Pay for bundle size with payload size. By doing more work on the server, you can avoid having to send code to the client. But as a tradeoff you make each response payload bigger than it was. This might not matter if you had inefficient data patterns anyways, but atleast you had the capability to really optimize how much data is sent back and forth (see GraphQL). RSCs help you optimize for bundle size instead of payload size. 2 - Server-first vs client-first architecture. The way RSCs are intended to be used are with a server-first routing architecture (aka Next.js and Waku) rather than client first (aka Remix and Tanstack Start). You still have #1 with client first, but opting into server-first brings a whole set of tradeoffs of its own, like eliminating client-server waterfalls at the cost of granular refetching. You can get granular refetching with RSCs with a bit of work, and you can eliminate server waterfalls in a client-first architecture with a bit of work. But the architecture bakes that tradeoff fundamentally. Any other advantage that people might tell you to sell RSCs like full-stack composition or client-server colocation are true, but they are not unique to RSCs. Server functions give you all of that, even in non-react frameworks, and don't force any tradeoffs like RSCs do. You might not need RSCs.

TIL from @RobKnight__ that Metro (React Native bundler) doesn't support tree shaking

The New Architecture is here! React Native 0.76 enables the New Architecture by default: reactnative.dev/blog/2024/10…