Turbopack, the successor to Webpack(vercel.com)
vercel.com
Turbopack, the successor to Webpack
https://vercel.com/blog/turbopack
312 comments
From my experience working with esbuild since it's early days, all I can say is to that there has been a very high bar set by esbuild's speed and ease-of-use. I've used it for all my web apps and services since and i've finally begun to like my front-end build chain, unbelievably.
These bundlers do not do the same work as webpack. Turbopack is using swc for typescript which means it will not do typechecking during compilation which effectively makes it fairly useless as a compiler. Now, if you only want bundling and minification then sure but why would anyone want only bundling? Good luck having a sensible workflow when your type checking has to run separately and perfectly match whatever typescript version is hidden inside your bundler, good luck dealing with constant mismatches when there are errors on either side.
EDIT: The responses pointed out that the author is the maintainer of webpack, I removed that part of the comment calling it deceptive. Maybe the entire intent is to deprecate webpack. I still think that it should be renamed to "Turbopack: our webpack successor" because calling it 'the' successor is a bit presumptuous and the article doesn't even directly say that.
EDIT: The responses pointed out that the author is the maintainer of webpack, I removed that part of the comment calling it deceptive. Maybe the entire intent is to deprecate webpack. I still think that it should be renamed to "Turbopack: our webpack successor" because calling it 'the' successor is a bit presumptuous and the article doesn't even directly say that.
Wow remote caching like Bazel is wild to see in a bundler. It's nice to see someone realize that JS bundling is more or less like compiling and linking in the native code world and we just need to accept it and optimize the hell out of it.
Really hope this gets a competent library mode. Webpacks library mode never really evolved to meet the needs of things. Vite has a good library mode but it has its own limitations.
Pure rollup is still the best for building libraries, by and large (maybe esbuild now? but I think rollup is more efficient in its output still).
If this has a good, solid library mode that works like rollup with the power of the webpack-like asset graph, it'd actually be amazing for the community as a whole.
Pure rollup is still the best for building libraries, by and large (maybe esbuild now? but I think rollup is more efficient in its output still).
If this has a good, solid library mode that works like rollup with the power of the webpack-like asset graph, it'd actually be amazing for the community as a whole.
Surprised not to see much mention of plugins and how they will work (unless I missed something?).
Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?
Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?
Bummer that we have to wait for Svelte support, but seems worth it. Hope to see it bundled with Svelte Kit soon!
https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
A bit of a bummer that "get started" requires nextjs, and there's no documentation for a frameworkless build (I understand it's labeled as alpha but if you're going for such grandiose announcement an "how to bundle a vanilla/frameworkless app" would have been nice)
Literally 1 day after my team migrates our build to Vite :')
> Currently, migrating to Turbopack from Webpack is not yet possible
Bummer! Do I need a turbopack.config.js?
I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently.
> [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API]
Will I be able to use my current plugins? Where does config for these plugins live?
> [SCSS and LESS] don't currently work out-of-the-box with Turbopack
Keep it this way! LESS has been dead and SCSS dying. Focus on CSS Modules please!
Bummer! Do I need a turbopack.config.js?
I've still got my package.json, tsconfig.json, .env, and postcss.config.js apparently.
> [Turbopack cannot currently be configured with plugins. We plan to make Turbopack extensible, likely with an altered API]
Will I be able to use my current plugins? Where does config for these plugins live?
> [SCSS and LESS] don't currently work out-of-the-box with Turbopack
Keep it this way! LESS has been dead and SCSS dying. Focus on CSS Modules please!
Is there a place I can find a "current state of the art" on this stuff? Once upon a time a quick-start option would have been. For instance, I may have done Rails+React+Babel+Webpack to get a quick backend JSON-API and a front-end web-app that consumes it.
Not for something that "scales to 100 teams", just something for me to spin an app up in quickly. i.e. 0 to 1 is the only thing that matters.
Not for something that "scales to 100 teams", just something for me to spin an app up in quickly. i.e. 0 to 1 is the only thing that matters.
All these lazy graph recompute reminds me of 90s dag based "procedural" modelers who achieved near real time re-rendering of extremely complex data through just that.
I assume the mainstream is ready to swallow the idea.
I assume the mainstream is ready to swallow the idea.
Very excited for this if the configuration and behavior is 1:1 with Webpack. The primary reason I haven't moved to other "more efficient" build tools is having to learn how to do various optimizations and getting the artifacts I expect.
Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. Vite and esbuild are fast enough, and I feel the winner will be more about usability, docs, easy config, etc.
That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs turbo. I just wanna `script/build` or `yarn dev` and not think about it anymore.
It seems like collaboration and consolidation around common tooling is just impossible and not even considered a possibility at this point. We are forever stuck in this world of special snowflake build toolchains for damn near every app that wants to use modern JS.
That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs turbo. I just wanna `script/build` or `yarn dev` and not think about it anymore.
It seems like collaboration and consolidation around common tooling is just impossible and not even considered a possibility at this point. We are forever stuck in this world of special snowflake build toolchains for damn near every app that wants to use modern JS.
I will be completely honest, Next.js is amazing and with each version it is getting better. This turbopack thing, I think they made mistake and it is distraction. This is not a problem anyone had, at least that I know. Vite is amazing and they should've built on work of others.
This is one of the Rust things, we just have to build everything from scratch :).
This is one of the Rust things, we just have to build everything from scratch :).
Feels like the rails community is going to be confused by the naming.
If it combines the flexibility of Webpack with the performance of esbuild this is going to be great.
Parcel is another one of these that started promising but the longer we use it the more issues crop up (caches need to be pruned, performance issues).
Curious if this will be supported by react-scripts. Or is it Next.js-specific?
I read this while taking a break from trying to find the problem with our pnpm/turborepo monorepo. Works in a clean devcontainer, fails in CI, fails on multiple dev machines.
Currently. I’m skeptical.
Currently. I’m skeptical.
Are the benchmarks used for generating the results on the website available for us to poke around in? https://turbo.build/pack
I'm curious about the "Cold Start" time for 30k modules taking 20s, which still doesn't feel like the best possible experience, even though it's a significant improvement over the other contenders listed.
Is there a separate, faster "Warm Start" time after everything is cached? Or is this it?
I'm curious about the "Cold Start" time for 30k modules taking 20s, which still doesn't feel like the best possible experience, even though it's a significant improvement over the other contenders listed.
Is there a separate, faster "Warm Start" time after everything is cached? Or is this it?
Been loving vite these days and can’t think of a compelling reason to leave that ecosystem - but I’ll take this for a spin for sure.
You either die a JavaScript fanboy, or you webdev long enough to see yourself walk away from the unending parade of needlessness.
Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.
Ah, so this is why Vercel hired Tobias. Makes sense, and it could only gain traction with a company like Vercel behind it. Webpack is legacy now, supplanted by Rollup/Vite, ESBuild, et al. The only folks I know still using webpack are stuck with it (e.g. Next users)
Remember jikes - the java compiler written in c (or something)?
I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end.
How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.
I think writing build tools for JavaScript in anything other than JavaScript (or language that compiles to js) is a dead end.
How would you write a plug-in to this? Or a programmatic configuration. So much gained from staying on js.
A rather niche question: The blog says Turbopack is fast thanks to using Turbo, a library for incremental memoization. I wonder how Turbo tcompares to Salsa, the latter which was developed in tandem with rust-analyzer.
How does it compare to bun. That is what got me excited after a very long time.
The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…
What differs webpack from other "bundlers" is
it's plugins ecosystem. I use couple of them at the moment
in my workflow and that's the main reason I won't migrate to turbo for some time.
At least not until porting will happen.
https://turbo.build/pack/docs/migrating-from-webpack#will-we...
Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the browser and node.
I am manly building client side react applications, so your mileage may vary.
[1] https://parceljs.org/
[2] https://parceljs.org/getting-started/library/
[3] https://parceljs.org/getting-started/webapp/