TL;DR, they had a better look at their dependencies, applied code splitting, and used Rollup. They updated their build from the initial 2014 version, at long last.
Something webpack doesn't get right to this day: building consumable libraries.
It has all the bones, and it would be great if it did, as its extremely powerful at manipulating the AST as part of the process etc so you could do some neat optimizations, but it won't output to a standard format, even with experimental ESM output feature enabled, that makes the library reasonably consumable.
Rollup / Vite really excel here but I love competition pushing things forward, meaning webpack having a better library building experience would be a good thing.
It's bad for them because their support matrix still includes versions of Node and webpack that haven't been in even LTS support for years at this point.
It's great that they want to support such a long tail. I know that makes a lot of developers very happy that they can rely on that.
In my experience ESM is not painful at all if you can rip the bandaid off and drop Webpack 4 (and below) and any version of Node less recent than current LTS. That's a lot easier done in greenfield projects than those that have long tail support matrices to contend. Brownfield projects should get better as more and more of that tail dies off.
opposite issue, webpack doesn't output plain ESM code for libraries (IE, no __webpack__require__ etc.). Its both experimental and sometimes completely incorrectly generated, while still generating library code with webpack specific references.
My complaint with esbuild is it doesn't use `tslib` nor does it have its own sharable helpers like it that can be shared across builds, so you have all this repeated code that doesn't treeshake away.
If it did, I'd use esbuild in a heartbeat for libraries.
It also uses generic polling for watchmode, I'd like to see something more robust
Can't say I've every used esbuild for watching, mostly because if I'm running in dev mode, I'm going to load "my files", not a bundle. The bundle is only for final delivery, so it needs to pass tests, but that's a precommit step, not a continuous development process.
monorepo setups is where you will likely find this to be more of an issue, especially if you spin up watch mode on several libraries that may be undergoing changes
At this point in my life I think "DX" - if you mean things like performance, reliability, simplicity and maintainability - is inversely proportional to the amount of (transitive) dependencies, layers of abstraction and (only half jokingly) also the percentage of JS that something includes.
I've encountered a pretty back breaking memory leak in vite that has been unresolved for about 2y now. The project I work on that uses vite doesn't need the flexibility, feature set and plugin system that vite offers. It just needs a fast bundler.
Yeah.. I think the two things I'd look for first on older codebases would be removing and JS shims and looking for larger libraries like moment and similar that can be removed. Expressly lazy loading any graph/chart libraries helps a lot too.
I'd probably reach for vite or parcel for a bundler, but using Rollup directly is okay.
