diff --git a/docs/pages/blog/turbopack-benchmarks.mdx b/docs/pages/blog/turbopack-benchmarks.mdx index 0a5b498d527ac..df5ba24127089 100644 --- a/docs/pages/blog/turbopack-benchmarks.mdx +++ b/docs/pages/blog/turbopack-benchmarks.mdx @@ -1,7 +1,7 @@ --- title: "Turbopack Performance Benchmarks" date: 2022/10/31 -description: "Benchmarking Turbopack performance against Vite and Webpack." +description: "Benchmarking Turbopack performance against Vite and webpack." tag: "web development" ogImage: "/images/blog/turbopack-benchmarks/twitter-card.png" --- @@ -33,7 +33,7 @@ import Date from "../../components/blog/Date"; At [Next.js Conf](https://nextjs.org), [we announced](https://www.youtube.com/watch?v=NiknNI_0J48) our latest open-source project: Turbopack, an incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust. -The project began as an exploration to improve Webpack’s performance and create ways for it to more easily integrate with tooling moving forward. In doing so, the team realized that a greater effort was necessary. While we saw opportunities for better performance, the premise of a new architecture that could scale to the largest projects in the world was inspiring. +The project began as an exploration to improve webpack’s performance and create ways for it to more easily integrate with tooling moving forward. In doing so, the team realized that a greater effort was necessary. While we saw opportunities for better performance, the premise of a new architecture that could scale to the largest projects in the world was inspiring. In this post, we will explore why Turbopack is so fast, how its incremental engine works, and benchmark it against existing approaches. @@ -45,7 +45,7 @@ This does not work like traditional caching where you look up a result from a ca Instead, Turbopack skips work altogether for cached results and only recomputes affected parts of its internal dependency graph of functions. This makes updates independent of the size of the whole compilation, and eliminates the usual overhead of traditional caching. -## Benchmarking Turbopack, Webpack, and Vite +## Benchmarking Turbopack, webpack, and Vite We created a test generator that makes an application with a variable amount of modules to benchmark cold startup and file updating tasks. This generated app includes entries for these tools: @@ -54,7 +54,7 @@ We created a test generator that makes an application with a variable amount of - Next.js 13 with Turbopack - Vite -As the current state of the art, we are including [Vite](https://vitejs.dev/) along with Webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module. +As the current state of the art, we are including [Vite](https://vitejs.dev/) along with webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module. @@ -173,7 +173,7 @@ We report the linear regression slope of the data points as the target metric. T The takeaway: Turbopack performance is a function of **the size of an update**, not the size of an application. -For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [Webpack](/pack/docs/comparisons/webpack). +For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [webpack](/pack/docs/comparisons/webpack). #### Data @@ -210,7 +210,7 @@ Visit the [Turbopack benchmark documentation](/pack/docs/benchmarks) to run the ## The future of the open-source Web -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. +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. Our goal is to create a system of open source tooling that helps to build the future of the Web—powered by Turbopack. We are creating a reusable piece of architecture that will make both development and warm production builds faster for everyone. diff --git a/docs/pages/pack/docs/benchmarks.mdx b/docs/pages/pack/docs/benchmarks.mdx index 7d29f94359bef..41788a9991b44 100644 --- a/docs/pages/pack/docs/benchmarks.mdx +++ b/docs/pages/pack/docs/benchmarks.mdx @@ -13,7 +13,7 @@ We created a test generator that makes an application with a variable amount of - Next.js 13 with Turbopack - Vite -As the current state of the art, we're including [Vite](https://vitejs.dev/) along with Webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module. +As the current state of the art, we're including [Vite](https://vitejs.dev/) along with webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module. @@ -138,7 +138,7 @@ We report the linear regression slope of the data points as the target metric. T The takeaway from these benchmarks: Turbopack performance is a function of **the size of an update**, not the size of an application. -We're excited by Turbopack's performance, but we also expect to make further speed improvements for both small and large applications in the future. For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [Webpack](/pack/docs/comparisons/webpack). +We're excited by Turbopack's performance, but we also expect to make further speed improvements for both small and large applications in the future. For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [webpack](/pack/docs/comparisons/webpack). #### Data diff --git a/docs/pages/pack/docs/comparisons/webpack.mdx b/docs/pages/pack/docs/comparisons/webpack.mdx index 9a64d22cf3a81..a8b821a8e6b1d 100644 --- a/docs/pages/pack/docs/comparisons/webpack.mdx +++ b/docs/pages/pack/docs/comparisons/webpack.mdx @@ -1,31 +1,31 @@ --- -title: Turbopack vs. Webpack -description: Compare Turbopack vs. Webpack +title: Turbopack vs. webpack +description: Compare Turbopack vs. webpack --- import { DocsBenchmarksGraph } from '../../../../components/pages/pack-home/DocsBenchmarksGraph'; import { DocsBenchmarkStat } from '../../../../components/pages/pack-home/DocsBenchmarkStat'; import BenchmarksCallout from './BenchmarksCallout'; -# Comparing Turbopack and Webpack +# Comparing Turbopack and webpack -Webpack has been downloaded over 3 billion times, making it today's most common JavaScript bundler. However, we found that we'd hit the limits of what it could do with its JavaScript-based architecture. +webpack has been downloaded over 3 billion times, making it today's most common JavaScript bundler. However, we found that we'd hit the limits of what it could do with its JavaScript-based architecture. -We've built Turbopack as the successor of Webpack: much **faster**, but just as **flexible and extensible**. +We've built Turbopack as the successor of webpack: much **faster**, but just as **flexible and extensible**. ## Speed -Turbopack's incremental architecture outstrips Webpack's speed on several key metrics. +Turbopack's incremental architecture outstrips webpack's speed on several key metrics. ### Dev server startup time -The main problem we found with Webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page. +The main problem we found with webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page. We designed Turbopack to be as lazy as possible, only doing work when it's requested. In a dev server, this means on incoming requests we do **exactly the work the user asked for**. No more unnecessary bundling of on demand loaded code before the user needs it. You can learn more in our [core concepts docs](/pack/docs/core-concepts#compiling-by-request). -This means that Turbopack's dev server starts up much faster than Webpack. Next.js 12, which uses Webpack under the hood, can start up a build server on a 1,000 module application in . Turbopack starts up in - ** faster**. +This means that Turbopack's dev server starts up much faster than webpack. Next.js 12, which uses webpack under the hood, can start up a build server on a 1,000 module application in . Turbopack starts up in - ** faster**. ### Code updates -As we continued to optimize Webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds. +As we continued to optimize webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds. With Turbopack, we achieved the goal we were aiming for: Fast Refresh performance that stays near-constant, no matter your application size. Instead of scaling with your application size, it scales based on the size of the _changes made_. -In a 1,000 module application, Turbopack can react to file changes ** faster** than Webpack. In a 30,000 module application, this is ** faster**. +In a 1,000 module application, Turbopack can react to file changes ** faster** than webpack. In a 30,000 module application, this is ** faster**. ## Extensibility -Webpack has an extraordinary collection of [plugins](https://webpack.js.org/plugins/) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features. +webpack has an extraordinary collection of [plugins](https://webpack.js.org/plugins/) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features. -In its alpha state, Turbopack cannot currently be configured with plugins. In the future, we plan to make Turbopack just as extensible as Webpack - though likely with an altered API. +In its alpha state, Turbopack cannot currently be configured with plugins. In the future, we plan to make Turbopack just as extensible as webpack - though likely with an altered API. diff --git a/docs/pages/pack/docs/features/environment-variables.mdx b/docs/pages/pack/docs/features/environment-variables.mdx index 0b6c46667716a..4e6daec082a31 100644 --- a/docs/pages/pack/docs/features/environment-variables.mdx +++ b/docs/pages/pack/docs/features/environment-variables.mdx @@ -26,4 +26,4 @@ Not only that, but Turbopack will live reload when these values change. Restarti Environment variables will be injected into `process.env`. For instance, `DATABASE_URL` will be on `process.env.DATABASE_URL`. -This follows the tradition of Node.js, Webpack 5 and Next.js 12, which each use `process.env` for variable injection. +This follows the tradition of Node.js, webpack 5 and Next.js 12, which each use `process.env` for variable injection. diff --git a/docs/pages/pack/docs/features/static-assets.mdx b/docs/pages/pack/docs/features/static-assets.mdx index 3295fd31c6654..26ebf7ad2dff9 100644 --- a/docs/pages/pack/docs/features/static-assets.mdx +++ b/docs/pages/pack/docs/features/static-assets.mdx @@ -14,7 +14,7 @@ import audio from './audio.wav' ### Next.js -In Webpack and some other frameworks, importing an image returns a string containing that image's URL. +In webpack and some other frameworks, importing an image returns a string containing that image's URL. ```ts import img from './img.png'; diff --git a/docs/pages/pack/docs/index.mdx b/docs/pages/pack/docs/index.mdx index 27eb3f09674cc..93cec383b9e19 100644 --- a/docs/pages/pack/docs/index.mdx +++ b/docs/pages/pack/docs/index.mdx @@ -10,13 +10,13 @@ import FullTurboCTA from "../../../components/FullTurboCTA"; # Getting Started with Turbopack -Turbopack 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/). +Turbopack 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/). -On large applications Turbopack updates 10x faster than Vite and 700x faster than Webpack. For the biggest applications the difference grows even more stark with updates up to 20x faster than Vite. +On large applications Turbopack updates 10x faster than Vite and 700x faster than webpack. For the biggest applications the difference grows even more stark with updates up to 20x faster than Vite. The secret to Turbopack'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 Turbopack 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. +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. Turbopack is currently in alpha. It is not yet ready for production use. We appreciate your support and feedback as we work to make it ready for everyone. diff --git a/docs/pages/pack/docs/migrating-from-webpack.mdx b/docs/pages/pack/docs/migrating-from-webpack.mdx index 2d3299b43ade9..33c06991e363a 100644 --- a/docs/pages/pack/docs/migrating-from-webpack.mdx +++ b/docs/pages/pack/docs/migrating-from-webpack.mdx @@ -1,24 +1,24 @@ --- -title: Migrate from Webpack to Turbopack -description: Learn about how to migrate from Webpack to its Rust-powered successor, Turbopack. +title: Migrate from webpack to Turbopack +description: Learn about how to migrate from webpack to its Rust-powered successor, Turbopack. --- -# Migrating from Webpack to Turbopack +# Migrating from webpack to Turbopack -We're planning Turbopack as the successor to Webpack. In the future, we plan to give Turbopack all the tools needed to support your Webpack app. +We're planning Turbopack as the successor to webpack. In the future, we plan to give Turbopack all the tools needed to support your webpack app. -Currently, migrating to Turbopack from Webpack is **not yet possible**. In the future, we're planning to offer a smooth migration path for all Webpack users to join the Turbopack future. +Currently, migrating to Turbopack from webpack is **not yet possible**. In the future, we're planning to offer a smooth migration path for all webpack users to join the Turbopack future. -## Will it be compatible with Webpack's API? +## Will it be compatible with webpack's API? -Webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular. +webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular. -We're planning on making Turbopack very flexible and extensible, but we're **not planning 1:1 compatibility with Webpack**. This lets us make choices which improve on Webpack's API, and lets us optimize for speed and efficiency. +We're planning on making Turbopack very flexible and extensible, but we're **not planning 1:1 compatibility with webpack**. This lets us make choices which improve on webpack's API, and lets us optimize for speed and efficiency. -## Will we be able to use Webpack plugins? +## Will we be able to use webpack plugins? -Webpack plugins are a crucial part of Webpack's ecosystem. They let you customize your toolchain, giving you low-level tools to maximize your productivity. +webpack plugins are a crucial part of webpack's ecosystem. They let you customize your toolchain, giving you low-level tools to maximize your productivity. -Since we're not offering 1:1 API compatibility, most Webpack plugins won't work out of the box with Turbopack. +Since we're not offering 1:1 API compatibility, most webpack plugins won't work out of the box with Turbopack. -However, we're working on porting several of the most popular Webpack plugins to Turbopack. +However, we're working on porting several of the most popular webpack plugins to Turbopack. diff --git a/docs/pages/pack/docs/roadmap.mdx b/docs/pages/pack/docs/roadmap.mdx index d32af9aedc779..9bd7c975aa2c1 100644 --- a/docs/pages/pack/docs/roadmap.mdx +++ b/docs/pages/pack/docs/roadmap.mdx @@ -24,9 +24,9 @@ In the future, we plan to persist this cache to the file system, to speed up Tur Once persisting to the file system is working, we can build the next logical step: persisting to a remote cache. With Turborepo, we've already built [remote caching](/repo/docs/core-concepts/remote-caching) on Vercel. In the future, you'll be able to _share_ Turbopack's hyper-granular cache across your whole team, using the Vercel Remote Cache. -## Migration for Webpack users +## Migration for webpack users -To learn more about our future plans for Webpack integration, check out our [Migrating from Webpack](/pack/docs/migrating-from-webpack) page. +To learn more about our future plans for webpack integration, check out our [Migrating from webpack](/pack/docs/migrating-from-webpack) page. ## Fusion with Turborepo diff --git a/docs/pages/pack/docs/why-turbopack.mdx b/docs/pages/pack/docs/why-turbopack.mdx index 80f2c51779297..18cec9887af86 100644 --- a/docs/pages/pack/docs/why-turbopack.mdx +++ b/docs/pages/pack/docs/why-turbopack.mdx @@ -5,7 +5,7 @@ description: Learn why we think Turbopack is the future of bundling for the web. # Why Turbopack? -When we set out to create Turbopack, 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. +When we set out to create Turbopack, 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? @@ -17,7 +17,7 @@ Frameworks like Vite use a technique where they don’t bundle application sourc 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 Turbopack to bundle the code in the development server. Turbopack 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. +That’s why we decided that, like webpack, we wanted Turbopack to bundle the code in the development server. Turbopack 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 diff --git a/docs/pages/pack/index.mdx b/docs/pages/pack/index.mdx index 20a1a72319b8e..f1f71b14bdffb 100644 --- a/docs/pages/pack/index.mdx +++ b/docs/pages/pack/index.mdx @@ -1,5 +1,5 @@ --- -overrideTitle: "Turbopack - The successor to Webpack" +overrideTitle: "Turbopack - The successor to webpack" description: "Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust." ---