This now has really started to feel like the last days of Rome.
For context: https://rome.tools/
Turbopack, the successor to Webpack
21–30 of 331 posts
Re: Turbopack, the successor to Webpack
#22Wow 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.
Re: Turbopack, the successor to Webpack
#23Wow 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.
speaking of which, is it reasonable to use Bazel instead of webpack?
Re: Turbopack, the successor to Webpack
#24Very 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.
> 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 let us optimize for speed and efficiency.
Re: Turbopack, the successor to Webpack
#25Is 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.
Re: Turbopack, the successor to Webpack
#26Literally 1 day after my team migrates our build to Vite :')
At least that is stable now, be happy
Re: Turbopack, the successor to Webpack
#27Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.
according to the article, Turbopack is 10-20x faster than Vite. I wonder how they were able to edge it out so significantly!
Vite uses esbuild for transpiling and rollup for bundling. esbuild (written in go) is already pretty fast for transpiling but there might be a lot of possibilities to optimize in rollup as rollup is written in JavaScript.
Re: Turbopack, the successor to Webpack
#28Wow 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.
speaking of which, is it reasonable to use Bazel instead of webpack?
Bazel is just the infrastructure to run webpack. You'd need to do some work to make webpack's state be cacheable (I dunno what options and such it has for this, maybe it's already there as an option). But if you're looking at Bazel for JS work you probably just want to use the existing and maintained rules for it: https://github.com/bazelbuild/rules_nodejs It's been a while since I last looked at it but I don't think it has any caching for webpack.
Re: Turbopack, the successor to Webpack
#29Literally 1 day after my team migrates our build to Vite :')
At least that is stable now, be happy
Stable API perhaps, but vite has issues with memory leaks, which can break builds in CI.
Re: Turbopack, the successor to Webpack
#30Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.
If the configuration is a nightmare like webpack then not likely.