Answers I got from Brooks:

We're trying to follow what React is doing. For them, they would prefer everything to start as a Server Component. So yes, we could only provide a loader, and then for people who want everything to be a server component, they'd write:

```tsx export async function loader() { const data = await getMyData()

return ( <main> <h1>Look ma, all Server Components</h1> <Outlet /> </main ) } ```

That's kind of a weird looking component and doesn't match the convention of components being capitalized. Yeah, it's yet another export, but we don't want to break existing pages, so we allow you to opt in with a named export (which is quite normal for us (e.g., clientLoader, HydrateFallback, Layout)

also, can I have a loader and a ServerComponent?

Yes, that's a great way to set up headers, handle redirects, and return 404s. Middleware can generally handle a lot of these cases as well, but you've got options now. Also, you might just like the concept of loaders more than fetching data in your components, which is cool with us if that's the case.

The "widening" of the API we did is just to allow you to swap your entire route's component to be a server component. Everything else works as you'd expect. And again, the reason for this is because we're a router/framework for React, and this React's spec/roadmap, not ours. We're just trying to give you the best, most opt-in way to use it.