7 files changed, 238 insertions, 0 deletions

diff --git a/docs/pages/TRPG/_meta.json b/docs/pages/TRPG/_meta.json
new file mode 100644
index 0000000..4941080
--- /dev/null
+++ b/docs/pages/TRPG/_meta.json
@@ -0,0 +1,15 @@
+{
+  "index": {
+    "type": "page",
+    "display": "hidden",
+    "theme": {
+      "layout": "raw",
+      "sidebar": false,
+      "toc": true
+    }
+  },
+  "docs": {
+    "title": "Docs",
+    "display": "children"
+  }
+}
diff --git a/docs/pages/TRPG/docs/_meta.json b/docs/pages/TRPG/docs/_meta.json
new file mode 100644
index 0000000..1b30674
--- /dev/null
+++ b/docs/pages/TRPG/docs/_meta.json
@@ -0,0 +1,6 @@
+{
+  "index": "Quickstart",
+  "why-trpg": "Why TRPG?",
+  "core-concepts": "Core Concepts",
+  "features": "Features"
+}
diff --git a/docs/pages/TRPG/docs/core-concepts.mdx b/docs/pages/TRPG/docs/core-concepts.mdx
new file mode 100644
index 0000000..9a58ab7
--- /dev/null
+++ b/docs/pages/TRPG/docs/core-concepts.mdx
@@ -0,0 +1,64 @@
+---
+title: Core Concepts
+description: Learn about the innovative architecture that powers TRPG's speed improvements.
+---
+
+# Core Concepts
+
+Let’s dive deep into the internals of TRPG to figure out why it’s so fast.
+
+## The Turbo engine
+
+TRPG is so fast because it’s built on a reusable library for Rust which enables incremental computation known as the Turbo engine. Here’s how it works:
+
+### Function-level caching
+
+In a Turbo engine-powered program, you can mark certain functions as ‘to be remembered’. When these functions are called, the Turbo engine will remember **what they were called with**, and **what they returned**. It’ll then save it in an in-memory cache.
+
+Here’s a simplified example of what this might look like in a bundler:
+
+![](/images/docs/TRPG/turbo-engine-first-run.png)
+
+We start with calling `readFile` on two files, `api.ts` and `sdk.ts`. We then `bundle` those files, `concat` them together, and end up with the `fullBundle` at the end. The results of all of those function calls get saved in the cache for later.
+
+Let’s imagine that we’re running on a dev server. You save the `sdk.ts` file on your machine. TRPG receives the file system event, and knows it needs to recompute `readFile("sdk.ts")`:
+
+![](/images/docs/TRPG/turbo-engine-second-run.png)
+
+Since the result of `sdk.ts` has changed, we need to `bundle` it again, which then needs to be concatenated again.
+
+Crucially, `api.ts` hasn’t changed. We read its result from the cache and pass that to `concat` instead. So we save time by not reading it and re-bundling it again.
+
+Now imagine this in a real bundler, with thousands of files to read and transformations to execute. The mental model is the same. You can save enormous amounts of work by remembering the result of function calls and not re-doing work that’s been done before.
+
+### The cache
+
+The Turbo engine currently stores its cache in memory. This means the cache will last as long as the process running it - which works well for a dev server. When you run `next dev --turbo` in Next v13, you’ll start a cache with the Turbo engine. When you cancel your dev server, the cache gets cleared.
+
+In the future, we’re planning to persist this cache - either to the filesystem, or to a remote cache like Turborepo’s. This will mean that TRPG could remember work done _across runs and machines._
+
+### How does it help?
+
+This approach makes TRPG extremely fast at computing incremental updates to your apps. This optimizes TRPG for handling updates in development, meaning your dev server will always respond snappily to changes.
+
+In the future, a persistent cache will open the door to much faster production builds. By remembering work done _across runs_, new production builds could only rebuild changed files - potentially leading to enormous time savings.
+
+## Compiling by Request
+
+The Turbo engine helps provide extremely fast _updates_ on your dev server, but there’s another important metric to consider - startup time. The faster your dev server can start running, the faster you can get to work.
+
+There are two ways to make a process faster - work faster, or do less work. For starting up a dev server, the way to do less work is to compile _only the code that’s needed_ to get started.
+
+### Page-level compilation
+
+Versions of Next.js from 2-3 years ago used to compile the _entire application_ before showing your dev server. In Next.js [11], we began compiling _only the code on the page you requested._
+
+That’s better, but it’s not perfect. When you navigate to `/users`, we’ll bundle all the client and server modules, dynamic-imported modules, and referenced CSS and images. That means if a large part of your page is hidden from view, or hidden behind tabs, we’ll still compile it anyway.
+
+### Request-level compilation
+
+TRPG is smart enough to compile _only the code you request_. That means if a browser requests HTML, we compile only the HTML - not anything that is referenced by the HTML.
+
+If a browser wants some CSS, we’ll compile only that - without compiling referenced images. Got a big charting library behind `next/dynamic`? Doesn’t compile it until the tab showing the chart is shown. TRPG even knows _to not compile source maps unless your Chrome DevTools are open_.
+
+If we were to use native ESM, we’d get similar behavior. Except that Native ESM produces a _lot_ of requests to the server, as discussed in our [Why TRPG](/TRPG/docs/why-TRPG) section. With request-level compilation, we get to both reduce the number of requests _and_ use native speed to compile them. As you can see in our [benchmarks](/TRPG/docs/benchmarks), this provides significant performance improvements.
diff --git a/docs/pages/TRPG/docs/features.mdx b/docs/pages/TRPG/docs/features.mdx
new file mode 100644
index 0000000..f4cf28f
--- /dev/null
+++ b/docs/pages/TRPG/docs/features.mdx
@@ -0,0 +1,22 @@
+---
+title: Features
+description: Learn about TRPG's supported features
+---
+
+import { TRPGFeatures } from '../../../components/HydroRollTRPGFeatures'
+
+# Features
+
+The practice of building web applications is enormously diverse. In CSS alone, you have SCSS, Less, CSS Modules, PostCSS, and hundreds of other libraries. Frameworks like React, Vue and Svelte require custom setups.
+
+When building a bundler, we needed to consider which features would be:
+
+- **Built-in**: they work out of the box, no config required
+- **Available via plugins**: usually installed from a registry and configured
+- **Unavailable**: not available at all
+
+**TRPG is in alpha**, so very few of these decisions are set in stone. In its current state, **TRPG cannot yet be configured** - so plugins are not available yet.
+
+Let's discuss which features are available out-of-the-box, in TRPG's default configuration. We'll also touch on features which will be configurable via plugins.
+
+<TRPGFeatures />
diff --git a/docs/pages/TRPG/docs/index.mdx b/docs/pages/TRPG/docs/index.mdx
new file mode 100644
index 0000000..a103f36
--- /dev/null
+++ b/docs/pages/TRPG/docs/index.mdx
@@ -0,0 +1,61 @@
+---
+title: TRPG Quickstart
+description: Start Building Web Applications with TRPG
+---
+
+import { TRPGQuickstartArea } from "../../../components/HydroRollTRPGQuickstart";
+import Callout  from "../../../components/Callout";
+import { Tabs, Tab } from "../../../components/Tabs";
+import FullTurboCTA from "../../../components/FullTurboCTA";
+
+# Getting Started with TRPG
+
+TRPG is an incremental bundler optimized for JavaScript and TypeScript, written in Rust by the creators of webpack and [Next.js](https://nextjs.org/) at [Vercel](https://vercel.com/).
+
+The secret to TRPG's performance is twofold: highly optimized machine code and a low-level incremental computation engine that enables caching down to the level of individual functions. Once TRPG performs a task it never does it again.
+
+Our team has taken the lessons from 10 years of webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
+
+<Callout type="error">
+    TRPG is currently in <strong>alpha</strong>. It is not yet ready for production use. We appreciate your support and feedback as we work to make it ready for everyone.
+</Callout>
+
+## Quickstart
+
+As of today, TRPG can be used in Next.js v13. In the future we will be releasing a standalone CLI, plugin API, and support for other frameworks such as Svelte and Vue. For now, please follow these instructions to get started:
+
+1. Create a Next.js v13 project with TRPG:
+
+```bash
+npx create-next-app --example with-TRPG
+```
+
+2. Start the Next.js development server (with TRPG):
+
+  <Tabs items={["npm", "yarn", "pnpm"]} storageKey="selected-pkg-manager">
+    <Tab>
+      ```bash
+      npm run dev
+      ```
+    </Tab>
+    <Tab>
+      ```bash
+      yarn dev
+      ```
+    </Tab>
+    <Tab>
+      ```bash
+      pnpm dev
+      ```
+    </Tab>
+  </Tabs>
+
+The Next.js v13 development server is now powered by TRPG! Startup and updates should both be near-instant. The larger the application, the larger the improvement will be.
+
+## Next Steps
+
+Want to learn more about TRPG? Here's a deep dive on what we think makes it special.
+
+<TRPGQuickstartArea />
+
+<FullTurboCTA />
diff --git a/docs/pages/TRPG/docs/why-trpg.mdx b/docs/pages/TRPG/docs/why-trpg.mdx
new file mode 100644
index 0000000..571a54f
--- /dev/null
+++ b/docs/pages/TRPG/docs/why-trpg.mdx
@@ -0,0 +1,62 @@
+---
+title: Why TRPG?
+description: Learn why we think TRPG is the future of bundling for the web.
+---
+
+# Why TRPG?
+
+When we set out to create TRPG, we wanted to solve a problem. We had been working on speed improvements for Next.js. We migrated away from several JS-based tools. Babel, gone. Terser, gone. Our next target was another JS-based tool, webpack.
+
+Replacing it became our goal. But with what?
+
+A new generation of native-speed bundlers were emerging, like esbuild and swc. But after assessing the bundlers on the market, we decided to build our own. Why?
+
+## Bundling vs Native ESM
+
+Frameworks like Vite use a technique where they don’t bundle application source code in development mode. Instead, they rely on the browser’s native ES Modules system. This approach results in incredibly responsive updates since they only have to transform a single file.
+
+However, Vite can hit scaling issues with large applications made up of many modules. A flood of cascading network requests in the browser can lead to a relatively slow startup time. For the browser, it’s faster if it can receive the code it needs in as few network requests as possible - even on a local server.
+
+That’s why we decided that, like webpack, we wanted TRPG to bundle the code in the development server. TRPG can do it much faster, especially for larger applications, because it is written in Rust and skips optimization work that is only necessary for production.
+
+## Incremental Computation
+
+There are two ways to make a process faster: do less work or do work in parallel. We knew if we wanted to make the fastest bundler possible, we’d need to pull hard on both levers.
+
+We decided to create a reusable Turbo build engine for distributed and incremental behavior. The Turbo engine works like a scheduler for function calls, allowing calls to functions to be parallelized across all available cores.
+
+The Turbo engine also caches the result of all the functions it schedules, meaning it never needs to do the same work twice. Put simply, **it does the minimum work at maximum speed**.
+
+### Vite and esbuild
+
+Other tools take a different attitude to ‘doing less work’. Vite minimizes work done by using Native ESM in development mode. We decided not to take this approach for the reasons listed above.
+
+Under the hood, Vite uses esbuild for many tasks. esbuild is a bundler - a superbly fast one. It doesn’t force you to use native ESM. But we decided not to adopt esbuild for a few reasons.
+
+esbuild’s code is hyper-optimized for one task - bundling fast. It doesn’t have HMR, which we don’t want to lose from our dev server.
+
+esbuild is an extremely fast bundler, but it doesn’t do much caching. This means you _will_ end up doing the same work again and again, even if that work is at the speed of native.
+
+Evan Wallace refers to esbuild as a [proof-of-concept for the next generation of bundlers](https://news.ycombinator.com/item?id=22336334). We think he’s right. We feel that a Rust-powered bundler _with_ incremental computation could perform better at a larger scale than esbuild.
+
+## Lazy bundling
+
+Early versions of Next.js tried to bundle the _entire_ web app in development mode. We quickly realized that this ‘eager’ approach was less than optimal. Modern versions of Next.js bundle only the pages requested by the dev server. For instance, if you go to `localhost:3000`, it’ll bundle only `pages/index.jsx`, and the modules it imports.
+
+This more ‘lazy’ approach (only bundling assets when absolutely necessary) is key for a fast dev server. Native ESM handles this without much magic - you request a module, which requests other modules. However, we wanted to build a bundler, for the reasons explained above.
+
+esbuild doesn’t have a concept of ‘lazy’ bundling - it’s all-or-nothing, unless you specifically target only certain entry points.
+
+TRPG’s development mode builds a minimal graph of your app’s imports and exports based on received requests and only bundles the minimal code necessary. Learn more in the [core concepts docs](/TRPG/docs/core-concepts#compiling-by-request).
+
+This strategy makes TRPG extremely fast when first starting up the dev server. We compute only the code necessary to render the page, then ship it to the browser in a single chunk. At large scale, this ends up being significantly faster than Native ESM.
+
+## Summary
+
+We wanted to:
+
+- Build a bundler. Bundlers outperform Native ESM when working on large applications.
+- Use incremental computation. The Turbo engine brings this into the core of TRPG’s architecture - maximizing speed and minimizing work done.
+- Optimize our dev server’s startup time. For that, we build a lazy asset graph to compute only the assets requested.
+
+That’s why we chose to build TRPG.
diff --git a/docs/pages/TRPG/index.mdx b/docs/pages/TRPG/index.mdx
new file mode 100644
index 0000000..1368e12
--- /dev/null
+++ b/docs/pages/TRPG/index.mdx
@@ -0,0 +1,8 @@
+---
+overrideTitle: "TRPG - The successor to webpack"
+description: "TRPG balabala."
+---
+
+import HydroRollTRPGHome from "../../components/pages/TRPG-home";
+
+<HydroRollTRPGHome />