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

51–60 of 331 posts

Re: Turbopack, the successor to Webpack

#51

Post by cercatrova »

akira2501 wrote: post #46
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…

How often is bundling happening relative to loading the bundle that 5 seconds of savings is pertinent? There's this fairly recent notion that speed rules everything. Perhaps maintainability and releasing non-alpha quality software could have a day or two in the sun as well?

On a large team, it happens quite often in the CI infrastructure, as well as testing on local machines.

> There's this fairly recent notion that speed rules everything

Recent? I'd say it's very old, then got outdated as everyone moved to dynamic slow languages like Ruby (for Rails), Python (Django) and JS because of their perceived productivity improvements over typed languages like Java around 15 years ago. The pendulum is simply swinging in the other direction now.

Re: Turbopack, the successor to Webpack

#52

Post by cercatrova »

arvigeus wrote: post #34
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…

Turbopack is just a bundler, while Rome is the whole package. I think only Deno strives for the same, but still can’t replace things like eslint

Sure, but Rome is being eaten by the other things Vercel has, such as SWC replacing Terser and Babel. Pretty soon all of Rome's niches will be already met by other tools, I'd wager. I think Rome simply does not have a large and well-funded enough team compared to Vercel and others like Vite.

Re: Turbopack, the successor to Webpack

#53

Post by aobdev »

wilg wrote: post #4

My prayers for another JavaScript bundler have finally been answered!

There's always such a mixed response when new web tooling gets posted here that I really can't tell if this is sarcastic or not.

Regardless, I like that this is fast and it is probably going to get a lot of adoption since it will be included with Next.js.

Re: Turbopack, the successor to Webpack

#54

Post by adammarples »

RussianCow wrote: post #50
thatswrong0 wrote: post #41

This looks great, but I feel like calling this a successor to Webpack in its current state is disingenuous, considering the roadmap literally says: “Currently, migrating to Turbopack from Webpack is not yet possible.” At least the marketing website is snazzy ¯\_(ツ)_/¯

Indeed. Calling it a "spiritual" successor would have been more honest.

Heir apparent maybe?

Re: Turbopack, the successor to Webpack

#55

Post by bombela »

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?

I have used bazel (with remote caching) to cache the output of webpack before.

Webpack was driving the typescript compilation and had some plugins/extra codegen steps to run too. I tried to move as much as possible to bazel but I quickly found out the JS ecosystem likes to produce massive balls of muds. Very hard to break down and separate the various steps.

Re: Turbopack, the successor to Webpack

#58

Post by o_m »

Scarbutt wrote: post #47

Is nextjs the modern rails?

Kinda, but not really. There are still lots of parts you'll have to implement yourself if you want to create a CRUD app. The mainly focus on the frontend part with the help from the backend.

Combine next.js with https://blitzjs.com/ and you'll have something that looks like rails.

Re: Turbopack, the successor to Webpack

#59

Post by jaxn »

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.

Re: Turbopack, the successor to Webpack

#60

Post by rsanheim »

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.

Post reply on HN