Sigh? I think the speed improvement is awesome.

It is awesome to see so much innovation, but it can be exhausting to keep up.

I'm quite alright with new tooling every six months when the new thing is orders of magnitude faster. If people want to compete to make my job as a frontend dev easier and faster, that is just fine.

Ideally we could learn how to make the existing tools better/faster and create software that can evolve rather than re-writing everything from scratch every six months.

I suspect at some point we hit the limit of the language performance. I can't imagine JavaScript beating Rust when both are written well.

There was many years before people started trying to replace Webpack.

True but webpack itself had a ton of churn and made practically no effort to maintain backwards compatibility causing a ton of work with each major update.

Hmm, I am using it since v2 and I disagree, it was not so bad. I saw a lot of people had overcomplicated configs that could be simplified a lot, I guess those had some problems upgrading... But mine never had much problems (and not just because my needs were simple...), I just removed some options when going to v4 and that's about it.

I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner.

One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.

There's a few facets to consider:

1. Does code written a particular way?

2. Does it need to be configured?

3. Does it conflict with other tooling?

4. Does it have limitations that are too restrictive?

5. Does it cause bugs/issues that are difficult to resolve?

The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug.

That might not be realistic to do 100%, but I think it's what all tools should be aiming for.