clarify "meta-framework"

text/0000-server-components.md

@@ -403,7 +403,7 @@ Although we have figured out many of the important fundamentals of Server Compon
 * **Developer Tools**. We consider first-class developer tools to be a prerequisite for officially releasing any React feature, including Server Components. Our goal is to provide an integrated developer experience for writing React apps that span the server and client. For example, the component inspector might show the Server Component hierarchy, even though those components don’t actually exist in the client tree. Similarly, developers would ideally be able to see server errors and logs show up on the client developer console and be able to breakpoint server code from the client source pane. We’re actively exploring some approaches to realize these ideas in an ergonomic and secure fashion.
 * **Routing**. As noted above, applications will generally need some integration with a router in order to map requests for pages into requests to render specific Server Components, and to transmit their rendered output to the client for final display. For the initial release we plan to integrate Server Components into one or more frameworks, which can then serve as a guide for how others can integrate routing. We’ll explore open questions around how routing can work as part of these first framework integrations.
 * **Bundling**. Server Components must be able to dynamically send Client Components to the client, including any metadata necessary for the client to fetch the appropriate bundle(s) from a static resource server such as a CDN. As noted in the [Naming Convention for Server/Client Components](#naming-convention-for-serverclient-components), bundlers also need to understand the conventions around `.server.js` and `.client.js` files and other Server Component-specific package.json conventions. This an area we are actively exploring in collaboration with projects such as Webpack and Parcel. This exploration includes research into different heuristics to find the most efficient bundling strategies.
-* **Pagination and partial refetches**. As noted above in [Update (Refetch) Sequence](#update-refetch-sequence) Sequence), the typical method of reloading a page is to reload it in full. However there are some cases where this is not desirable, such as during pagination. Ideally our app would only fetch the next N items instead of refetching all items that the user has seen up to that point. We are still investigating how best to model pagination with Server Components. For example, internally we are loading Server Components via GraphQL, and using our existing infrastructure for pagination in GraphQL to work around lack of pagination in Server Components. However, we are committed to developing a general solution within React for this use-case.
+* **Pagination and partial refetches**. As noted above in [Update (Refetch) Sequence](#update-refetch-sequence), the typical method of reloading a page is to reload it in full. However there are some cases where this is not desirable, such as during pagination. Ideally our app would only fetch the next N items instead of refetching all items that the user has seen up to that point. We are still investigating how best to model pagination with Server Components. For example, internally we are loading Server Components via GraphQL, and using our existing infrastructure for pagination in GraphQL to work around lack of pagination in Server Components. However, we are committed to developing a general solution within React for this use-case.
 * **Mutations and invalidations**. In our initial demo we simply clear all cached Server Components whenever an update occurs. This is a simple approach that works well for many apps, but some apps may require more sophisticated invalidation strategies. We are still investigating how to support a generic mechanism for more fine-grained cache invalidation as well as an approach for supporting “optimistic” mutations.
 * **Pre-rendering.** One approach for improving page transition times is to pre-render content that the user is likely to interact with. For example, if a user hovers over a link, the application may begin to eagerly load that page. We are still investigating how to support pre-rendering out of the box for applications using Server Components.
 * **Static Site Generation**. As with Client Components, Server Components can be rendered at runtime (on the server), build time (locally or on the server), or even some hybrid approach. We are still investigating how to best integrate Server Components and static site generation. For example, the Server Component output stream could be converted into an HTML stream, allowing “static” sites to still benefit from explicitly designed loading states. 
@@ -490,7 +490,7 @@ We are running an experiment with a small number of users on a single page, with
 
 ### Is this specific to Next.js?
 
-No. We *are* partnering with Next.js to build out an initial integration. However, Server Components are designed from the beginning to be used with any meta-framework or into custom application setups. Given the scope of Server Components — including router, bundler, and server/client coordination aspects — we felt that a high-quality initial integration would allow us to demonstrate the setup to other developers.
+No. We *are* partnering with Next.js to build out an initial integration. However, Server Components are designed from the beginning to be used with any framework or integrated into custom application setups. Given the scope of Server Components — including router, bundler, and server/client coordination aspects — we felt that a high-quality initial integration would allow us to demonstrate the setup to other developers.
 
 ### What is the adoption story?