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.

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.

Microsoft has been able to evolve Windows and Office and SQL Server for decades, with huge customer bases…

I mean, there’s really only so much you can do. If major changes are required, you can either make a significant new version with massive compatibility issues, splitting the community (ala Python 2 & 3). And even then, you’re still building off of the old code.

Or start from scratch and make something better.

Either way, you split the community, but at least with the new tool you can (hopefully) manage to make it a lot better than a refactor would have been. (In some areas, anyways.)

Plus, this allows the old project to continue on without massive breaking changes, something its users probably appreciate. And this old project can still create new major versions if needed, which is something you don’t get if you have a major refactor because everything meaningful gets shipped to the refactored version.

So I think spinning off a new project is a net good here. It doesn’t impact webpack very much unless people ditch it and stop maintaining it (unlikely). It lets them iterate on new ideas without maintaining compatibility. (Good, when the big issue with webpack is its complexity.)

So if the idea turns out to be bad, we haven’t really lost anything.

> instead of fixing the bloated megalith that webpack has become

Megalith? Isn't it super modular and configurable?

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.

I dig through other people’s codebases all day long. I really don’t want to do that in my free time as well. Especially to fix the garbage that they built in the first place.

It’s just not fun. And that’s one of the most important reasons I do this job.

Webpack was flexible and “good enough.” But it turns out rust-based bundlers are 10-100x faster and so the definition of “good enough” has changed, for good reason.

It’s hard to overstate how game changing this new wave of zero-config, ultrafast rust bundlers are for the day-to-day dev experience.

For me the age of JavaScript isn't particularly important. I just don't think any one of the well-known options are good enough that I would want the community to throw a big portion of support behind it.