Note that what Babel does and what Webpack does are orthogonal. They're frequently used together and the challenges of converting them from JS to native are similar, but the OP isn't really in "competition" with SWC.
Sure, well aware that Babel and Webpack are not the same thing.
SWC has a Webpack plugin, whereas ESBuild seems to aim to replace both Webpack and Babel. Correct me if I'm wrong.
This is a big reason why I think SWC is more likely to succeed, and why I say they're in "competition" since they overlap partially, even if it's not 1-1.
Hmm, I got a little thrown off by the words "bundler and minifier", which are both Webpack tasks. Scrolling further down I do see "JSX transformation" thrown in, which is definitely normally a Babel thing.
If this project is trying to replace everything in a single pass then yeah, it's probably doomed to failure. Not only from the ambition of the task, but from the lack of the modular structure that allows community support to thrive: anybody can write a Webpack loader or a Babel plugin without getting their hands dirty in those codebases. That doesn't seem to be the case here.
I think the intention of the project is somewhat different to "classic" transformation tasks, in that it intends to cover the 80% workflow - take some js files, a few libraries, and make an efficient bundle from it.
That's what I need to do often and exactly what's annoyingly time intensive with the current JavaScript tooling.
SWC has a Webpack plugin, whereas ESBuild seems to aim to replace both Webpack and Babel. Correct me if I'm wrong.
This is a big reason why I think SWC is more likely to succeed, and why I say they're in "competition" since they overlap partially, even if it's not 1-1.