One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependen

One way to think about it is that we want to change the shape of the curve as the app grows. In our experience, as apps become more complex and take on dependencies, the fixed cost of React is offset by all the product and other third party library code. You might think it's not a problem for small/hobby apps, but those often fail to track their bundle size, so they also have perf problems. So we want to change the shape of the curve instead of just "making React smaller". If React itself is really your bottleneck, use Preact. >And if a component is a ~10kb in JS size and their new JSON UI representation is ~1kb in size then if you request 20 renders of that component then over the wire it would be 20kb of fragments than the 10kb component...? Keep in mind that you can shift things between Client and Server very fluidly. That's very much the point of the proposal. If you refetch something twenty times over a small period, it might be a good candidate to move to the Client. On the other hand, on most navigations you have to fetch anyway (to get data), and so you might as well do a bunch of CPU work on the server and avoid sending abstraction bloat down. One part that's missing from the current demo is granular refetching. That's going to be an important piece (including for routing). So that the refetch happens for partial subtrees and not always from the top. We have a rough idea for how it should work but it's still on the TODO list (as many other things we mentioned as ongoing research).