This is a good write up on the workings. However, in actual use, Turbopack has severe limitations when compared to Webpack. I’ve been working on https://jsonquery.app and rely on the jq WASM dependency for the queries. But, Turbopack cannot handle importing a WASM binary or the glue code for it directly. The workaround is to have a script copy the binary to the public directory. But that's not all. jq-wasm has a dependency on the ‘fs’ module, even though no fs functions are used. But trying to resolve this in Turbopack is not possible and 2 days of fighting this was a waste of time.
Webpack solved this problem with a few lines in the next.config.ts
For now, I’m back to using Webpack with NextJS 16 with the —Webpack flag. Hope they allow this for future versions.
The technical approach here is solid. Fine-grained dependency tracking with automatic invalidation is the right way to do incremental compilation. The Rust implementation means it can actually handle large codebases without the JS runtime becoming the bottleneck.
But the skepticism in this thread about ecosystem fragmentation is valid. Vite won because it worked with the existing ecosystem, not against it. Turbopack requiring Rust for plugins limits who can extend it.
That said, if you're already locked into Next.js, this is a clear win. The question is whether Next.js's market position justifies a separate build tool or whether this accelerates the trend of frameworks becoming walled gardens.
The fact that there's no tangible plan for any plugin support in Turbopack is actually what made me not choose Next.js.
The answer for people who need basically any build plugin is "use the webpack mode", and I have zero faith in Vercel maintaining that past the next major version.
I guess we'll see whether they figure out a story for plugins by then.
Much less indeed, not all Webpack plugins capabilities are supported and now anyone that wants to make one has to learn Rust, which surely isn't the same as writing it in JavaScript.
The splitting communities effect always gets left out of these announcements, or gets positioned as something good.
Not to say it is the quip but I have had buggy builds with bun that requires sticking to esbuild, I think it was bundling prettier with many plugins into a single JS file.
I always do that sort of thing in Docker so never considered it could be a Linux-specific thing, maybe so.
Webpack solved this problem with a few lines in the next.config.ts
For now, I’m back to using Webpack with NextJS 16 with the —Webpack flag. Hope they allow this for future versions.
There are plenty of complaints on the NextJS subreddit, and here is a open thread on complaints with Turbopack https://github.com/vercel/next.js/discussions/77721
Looks the alternative is Rspack?
But the skepticism in this thread about ecosystem fragmentation is valid. Vite won because it worked with the existing ecosystem, not against it. Turbopack requiring Rust for plugins limits who can extend it.
That said, if you're already locked into Next.js, this is a clear win. The question is whether Next.js's market position justifies a separate build tool or whether this accelerates the trend of frameworks becoming walled gardens.
I personally love Vite and Remix.
The answer for people who need basically any build plugin is "use the webpack mode", and I have zero faith in Vercel maintaining that past the next major version.
I guess we'll see whether they figure out a story for plugins by then.
https://vite.dev/
rest of the JS community can't use turbopack, so they went with vite
But that is not representative of broader ecosystem.
The splitting communities effect always gets left out of these announcements, or gets positioned as something good.
I always do that sort of thing in Docker so never considered it could be a Linux-specific thing, maybe so.