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

111–120 of 331 posts

Re: Turbopack, the successor to Webpack

#111

Post by jscheel »

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.

Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™

Re: Turbopack, the successor to Webpack

#112

Post by cercatrova »

Eduard wrote: post #103
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 rabbi…

What are you running? I've done multiple large deployment for machine learning work and they all work fine, stuff like numpy, scipy, pandas, pytorch etc which are the primary technologies I've seen written in C++. I wouldn't expect normal libraries to be so however, since they're likely not speed critical; Django for example I'm pretty sure is just Python.

Re: Turbopack, the successor to Webpack

#113

Post by derekdahmer »

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.

That’s really not what’s going on here.

All the previous gen bundlers are written in JS and support a giant ecosystem of JS plugins. There’s no incremental way to migrate those projects to Rust. The benefit of these new bundlers is that they are literally full rewrites in a faster language without the cruft of a now mostly unnecessary plugin API.

And the “cost” of this? Some of these new bundlers are written by just 1 or 2 core contributors. Turns out with the benefit of hindsight you can make a much better implementation from scratch with far less resources than before.

Re: Turbopack, the successor to Webpack

#114

Post by Rapzid »

alalani1 wrote: post #56
ntonozzi wrote: post #38

Earlier quoted context omitted.

Some extra context: https://en.wikipedia.org/wiki/Fall_of_the_Western_Roman_Empi... .

Thought I was on Reddit and not HN for a second

Nah, for extra context you are here: https://news.ycombinator.com/item?id=33334857

Re: Turbopack, the successor to Webpack

#115

Post by jscheel »

onion2k wrote: post #83
JoshGlazebrook wrote: post #30

Earlier quoted context omitted.

If the configuration is a nightmare like webpack then not likely.

Webpack has a reputation that was deserved in early versions. More recently it's not so bad unless you have very specific needs. If all you're doing is building a standard app from things like JS or TS, a CSS processor, and maybe a framework you probably won't need more than half a dozen lines of config that you can paste from Webpack or your framework's docs.

Currently looking at a 1000 line webpack config..........

Re: Turbopack, the successor to Webpack

#116

Post by derekdahmer »

jscheel wrote: post #111
djbusby wrote: post #93

Earlier quoted context omitted.

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.

Well, that's what is really frustrating here. Turbopack is built by the creator of Webpack. So, instead of fixing the bloated megalith that webpack has become, they are just moving on to greener pastures. But this time it'll be different™

Webpack 5 was that push to fix the monolith. I would guess that after that herculean upgrade effort that the creator of Webpack has a pretty good idea of what’s fixable and what’s an inherent limitation of the existing tool.

Re: Turbopack, the successor to Webpack

#118

Post by shrimpx »

mklepaczewski wrote: post #98
shrimpx wrote: post #73

Earlier quoted context omitted.

Is rollup still a thing?

What do you mean by "still"? I just learned that it exists a month ago! I wish I was joking... JS is not my main language, true, but damn it's hard to keep up. I think it took me less time to be productive with Typescript than with webpack.

Yeah I just learned about Vite a few days ago, and Turbopack today.

Apparently rollup is used under the hood by Vite, and the plugins and config syntax are compatible, but I couldn't get my rollup config to work with Vite.

Re: Turbopack, the successor to Webpack

#119

Post by crucialfelix »

TheRealPomax wrote: post #19
jdelman wrote: post #14

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.

God, I hope not. If there's one part of webpack that needs a complete overhaul it's (1) how you set up complex workflow configurations and (2) proper documentation for all aspects of that. And yes, that's one thing. Code without docs is not production-ready code, but code with bad docs isn't even PoC-ready code.

I think webpack has overhauled 1 and 2 every major release.

Accordingly the docs and API and blogs are littered with a mish mash of all previous APIs.

Thats the whole problem with webpack-its always changing.

Re: Turbopack, the successor to Webpack

#120

Post by eins1234 »

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?

Post reply on HN