Re:Zero-Bundle-Size React Server Components
by danabramov on Monday December 21, 2020 @04:07PM
(#25499545)
We did experiment with some pretty aggressive compilation approaches a few years ago (see Prepack). Ironically our conclusion from this (which informed Server Components design) is that you don't want this to be done automatically. Because then you don't have precise control and confidence over what gets shipped to the client and what gets shipped to the server. One compiler bailout, and the difference in the bundle is huge. So you'd want to add a way to enforce things, and now we're back to manual annotations.
(We did have a prototype that does this, though.)
Re:Zero-Bundle-Size React Server Components
by eyelidlessness on Monday December 21, 2020 @04:15PM
(#25499647)
I have looked at Prepack! I was wondering if it would be revisited. I certainly understand that lack of confidence, though I think I'd worried more about the false negative: something should be available to the client, but for whatever reason the compiler couldn't identify it. That said, I think tooling could go a long way to address the false positive. For example, in Next.js dev mode, there's an indicator that says whether a page can be statically rendered. If there were tools that said "we've automatically marked this component for the client bundle" and allowed the dev to manually opt out if they're sure the component shouldn't be sent to the client, it's still nice to have for the non-pathological case.
Anyway, thanks for filling in more detail!
Re:Zero-Bundle-Size React Server Components
by danabramov on Monday December 21, 2020 @05:56PM
(#25500704)
For what it's worth, it is always possible to build an automatic approach on top of a manual one. Maybe somebody motivated will do it. :-)
Re:Zero-Bundle-Size React Server Components
by eyelidlessness on Monday December 21, 2020 @08:11PM
(#25501759)
I’ve seriously considered it! It seems like it would probably be a pretty big endeavor, but it would certainly be cool to have.
It’s also an interesting approach compared to some of the partial hydration approaches I’ve seen. They all seem to use either wrapper divs/spans (bad for all kinds of reasons) or adjacent script “markers” containing initial hydration data, which seems similar to the slots approach but doesn’t necessarily enable streaming/prioritizing certain content for first render.
Since you’re here, I know the RFC discusses compile time static analysis to identify content which could be server-/static-only, but is there any consideration for supporting that where better static analysis is available (e.g. TypeScript/Flow)? I don’t mind manually marking components static or dynamic if it means a better UX, but doing it automatically in the compiler/bundler could be great for DX, as well as for preventing mistakes.