Update README

Author: mjackson

README.md

@@ -1,17 +1,27 @@
-This collection of packages empowers you to build modern web applications with maximum interoperability and portability, leveraging the power of web standards. Whether you're using [Remix](https://remix.run) or another framework, these tools are designed to seamlessly integrate into your workflow.
+# Welcome to Remix 3!
 
-This repository is laying the groundwork for the next major evolution of Remix.
+This branch (`v3`) is the source for Remix 3. It is under active development.
 
-## Philosophy
+We published [a blog post](https://remix.run/blog/wake-up-remix) earlier this year with some of our thoughts around Remix 3. It explains our philosophy for web development and why we think the time is right for something new. In particular, we follow these principles:
 
-Our core philosophy is simple: **build on web standards, embrace single responsibility.**
+1. Model-First Development. AI fundamentally shifts the human-computer interaction model for both user experience and developer workflows. Optimize the source code, documentation, tooling, and abstractions for LLMs. Additionally, develop abstractions for applications to use models in the product itself, not just as a tool to develop it.
+2. Build on Web APIs. Sharing abstractions across the stack greatly reduces the amount of context switching, both for humans and machines. Build on the foundation of Web APIs and JavaScript because it is the only full stack ecosystem.
+3. Religiously Runtime. Designing for bundlers/compilers/typegen (and any pre-runtime static analysis) leads to poor API design that eventually pollutes the entire system. All packages must be designed with no expectation of static analysis and all tests must run without bundling. Because browsers are involved, `--import` loaders for simple transformations like TypeScript and JSX are permissible.
+4. Avoid Dependencies. Dependencies lock you into somebody else's roadmap. Choose them wisely, wrap them completely, and expect to replace most of them with our own package eventually. The goal is zero.
+5. Demand Composition. Abstractions should be single-purpose and replaceable. A composable abstraction is easy to add and remove from an existing program. Every package must be useful and documented independent of any other context. New features should first be attempted as a new package. If impossible, attempt to break up the existing package to make it more composable. However, tightly coupled modules that almost always change together in both directions should be moved to the same package.
+6. Distribute Cohesively. Extremely composable ecosystems are difficult to learn and use. Therefore the packages will be wrapped up into a single package as dependencies and re-exported as a single toolbox (remix) for both distribution and documentation.
 
-Each package in this repository:
-- Adheres to the [single-responsibility principle](https://en.wikipedia.org/wiki/Single-responsibility_principle).
-- Prioritizes web standards to ensure maximum interoperability and portability across JavaScript runtimes.
-- Augments standards unobtrusively where they are missing or incomplete, minimizing incompatibility risks.
+## Goals
 
-This approach means the JavaScript you write is **portable by default**. These packages work seamlessly across [Node.js](https://nodejs.org/), [Bun](https://bun.sh/), [Deno](https://deno.com/), [Cloudflare Workers](https://workers.cloudflare.com/), and other environments.
+The goal is to develop all packages independently, and then stitch them together into the `remix` package for ease of use. However, all packages that make up Remix should be usable standalone as well. This forces us to consider package boundaries and helps us keep public interfaces portable and interopable.
+
+Each package in Remix:
+
+- Has a [single responsibility](https://en.wikipedia.org/wiki/Single-responsibility_principle)
+- Prioritizes web standards to ensure maximum interoperability and portability across JavaScript runtimes
+- Augments standards unobtrusively where they are missing or incomplete, minimizing incompatibility risks
+
+This approach means the Remix code you write is **portable by default**. These packages work seamlessly across [Node.js](https://nodejs.org/), [Bun](https://bun.sh/), [Deno](https://deno.com/), [Cloudflare Workers](https://workers.cloudflare.com/), and other environments.
 
 We leverage server-side web APIs like:
 
@@ -20,13 +30,13 @@ We leverage server-side web APIs like:
 - [The Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) instead of the Node.js crypto library
 - [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob) and [`File`](https://developer.mozilla.org/en-US/docs/Web/API/File) instead of some bespoke runtime-specific API
 
-The benefit? Code that's not just reusable, but **future-proof**.
+The benefit is code that's not just reusable, but **future-proof**.
 
-The goal is that these packages should be useful for anyone who is building for the web. If you're using [Remix](https://remix.run), we've designed it from the start to work with web standards. If you're using some other framework, you should easily be able to integrate these tools into your workflow as well without going full-blown Remix. If you're building your own framework, we hope you'll be able to build on this foundation as well.
+These packages should be useful for anyone who is building for the web. If you're using [Remix](https://remix.run), we've designed it from the start to work with web standards. If you're using some other framework, you should easily be able to integrate these tools into your workflow as well without going full-blown Remix. If you're building your own framework, we hope you'll be able to build on this foundation as well.
 
 ## Packages
 
-Discover our growing suite of tools:
+We currently publish the following packages:
 
 - [fetch-proxy](packages/fetch-proxy): Seamlessly construct HTTP proxies with the familiar `fetch()` API – ideal for API gateways or abstracting microservices.
 - [file-storage](packages/file-storage): Robust key/value storage tailored for JavaScript `File` objects, simplifying file management.
@@ -37,28 +47,6 @@ Discover our growing suite of tools:
 - [node-fetch-server](packages/node-fetch-server): Build Node.js HTTP servers using the web-standard `fetch()` API, promoting code consistency.
 - [tar-parser](packages/tar-parser): A fast, streaming parser for tar archives, designed for efficient data extraction.
 
-## Why Choose These Packages?
-
-- **Web Standard-Focused:** Write code that's portable across Node.js, Deno, Bun, Cloudflare Workers, and more.
-- **Single Responsibility:** Each package is focused and does one thing well, making them easy to understand and integrate.
-- **Interoperable:** Designed to work together, and with your existing tools, thanks to their adherence to web standards.
-- **Future-Proof:** By building on web standards, your codebase remains adaptable and resilient to ecosystem changes.
-- **Remix Ready (and Beyond!):** While born from the needs of Remix, these packages are valuable for any web developer or framework author seeking robust, standard-compliant tools.
-
-## Using with Remix v2
-
-If you're trying to use these libraries with Remix v2, you'll need to [enable "Single Fetch"](https://remix.run/docs/en/main/guides/single-fetch#enabling-single-fetch) first. This tells Remix to use Node's built-in fetch primitives (`Request`, `Response`, `Headers`, etc.) instead of a broken polyfill we shipped in earlier versions of Remix.
-
-## Quick Start
-
-Each package is available on npm and can be installed using:
-
-```bash
-npm install <package-name>
-```
-
-Then, import and use as needed in your project. Refer to individual package `README` files for specific usage instructions.
-
 All packages are published in both modern ESM and legacy CJS formats for maximum compatibility with both existing and new projects.
 
 ## Contributing