Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

Post reply on HN
Print view View original

101–110 of 331 posts

Re: Turbopack, the successor to Webpack

#101

Post by eurasiantiger »

michaelmior wrote: post #80
rsanheim wrote: post #60

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 tu…

> Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. I think it really depends on the use case. I use Webpack, but it's all configured for me by create-react-app and I don't have to mess with it. If my configuration could automatically be ported from Webpack to Turbopack and my builds got faster, great :) Of course, that's not the only use case and I agree tha…

    // @TODO implement and publish
   import { webpackConfigTranslator as translate } from ”turbopack-webpack-compat”;
   import webpackConfig from ”./webpack.config.js”;

   const turbopackConfig = translate(webpackConfig);

   export default turbopackConfig;
Any takers?

Re: Turbopack, the successor to Webpack

#102

Post by hamandcheese »

colordrops wrote: post #23
qbasic_forever wrote: post #22

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.

speaking of which, is it reasonable to use Bazel instead of webpack?

With rules_nodejs you can transform your source with whatever node-based packages you’d like. But be prepared to be more or less entirely on your own to figure out how to make it all work.

Oh and if you create many smaller packages (as is best practice in bazel to get good cache efficiency and parallel builds) be prepared for nonexistent editor/IDE support.

Re: Turbopack, the successor to Webpack

#103

Post by Eduard »

cercatrova wrote: post #7

As Lee Robinson mentioned and as I had said before [0], Rust and other compiled languages are the future of tooling. We should optimize for speed for tooling, not only whether people can contribute to it or not. We can always have a JS layer for configuration while the core runs in Rust, much like for many Python libraries, the interface is in Python while the computation happens in C++. I was also looking forward to…

> We can always have a JS layer for configuration while the core runs in Rust, much like for many Python libraries, the interface is in Python while the computation happens in C++.

And this behind-the-scenes-native code-but-pretending-to-be-Python is the reason why most Python stuff I try fails to run on the first tries.

Half of them I give up because I don't get them running after going down the weirdest error rabbit holes.

No matter whether Debian, Ubuntu, Windows 7/10, Cygwin, WSL2, Raspberry Pi, x64, ARM ...

Re: Turbopack, the successor to Webpack

#104

Post by WorldMaker »

cldellow wrote: post #69
rsanheim wrote: post #60

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 tu…

> special snowflake build toolchains That reminds me, wasn't there a build tool called Snowflake? Oh, it was called Snowpack [1]. And it's no longer being actively maintained. Yeesh. [1]: https://www.snowpack.dev/

My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up).

I know Vite inherited the first part, but I still mostly disagree with Vite on switching the default of that last part: it always bundles Production builds and switching that off is tough. Bundling is already starting to feel like YAGNI for small-to-medium sized websites and web applications between modern browser ESM support, modern browser "ESM preload scanners", and ancient browser caching behaviors, even without HTTP/2 and HTTP/3 further reducing connection overhead to almost none.

But a lot of projects haven't noticed yet because the webpack default, the Create-React-App default, the Vite default, etc is still "always bundle production builds" and it isn't yet as obvious that you may not need it and we could maybe move on away from bundlers again on the web.

Re: Turbopack, the successor to Webpack

#105

Post by tln »

fabiospampinato wrote: post #88

Is there any actual proof that Turbopack is 10x faster than Vite at anything? I can't find any benchmark showing it.

I'm a little skeptical as well. Vite is fast

I just checked a code base that's at ~900 modules, and vite is ready to serve dev requests in well under a second.

Re: Turbopack, the successor to Webpack

#108

Post by ohmahjong »

fabiospampinato wrote: post #88

Is there any actual proof that Turbopack is 10x faster than Vite at anything? I can't find any benchmark showing it.

Here is the benchmark section of the site, although I don't see a definitive source for what is being run.

* https://turbo.build/pack/docs/benchmarks

Re: Turbopack, the successor to Webpack

#109

Post by domoritz »

no_wizard wrote: post #84

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-l…

Yes. I mostly build libraries and rollup still beats everything in compatibility (esm, umd, cjs, etc) and output quality. It's slow, though, and I would love a faster alternative. Esbuild doesn't do tree shaking as well as rollup.

Re: Turbopack, the successor to Webpack

#110

Post by josephg »

djbusby wrote: post #93
andsoitis wrote: post #82

Earlier quoted context omitted.

We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.

By my count its 23 years. The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?) And we end up with basically: "I'll build my own moonbase with blackjack and hookers!" All that starting from scratch costs loads of impossible-to- recover-time.

Yeah. I’m consistently surprised and disappointed by how much resistance people have to getting their hands dirty digging through other people’s codebases. It’s fantastically useful, and a remarkable way to learn new approaches and techniques.

The world doesn’t need yet another JS bundler. It needs the one js bundler that works well with the wide variety of niche use cases.

Post reply on HN