Exactly: 99% of the time, "webpack is slow" is just code for "I have Babel in my toolchain" and forgetting to set ts-loader as "transpile only".
Personally I removed it years ago, and Webpack 5 even allowed me to get rid of more loaders now that there are Assets Modules that automatically detect assets and webworkers using the "new URL()" syntax, and Typescript does everything else I need.
Even if your target platform didn't have ES6 modules, Babel is probably not the tool you'd want to transpile those with. Let the bundler (which is the topic of the discussion here so I assume a bundler is used) handle them. Tree shaking works better that way anyway.
Also if JSX or similar JS extensions are the only thing you need tramspiling for, you might want to look at Sucrase [1] as a fast alternative to Babel.
Yep, I needed to put together a Webpack build tool chain for React last month & thought it was going to be a bit of a nightmare and it just...wasn't. Tiny bit of fiddling, but generally easy -- that was with a fairly complex setup in terms of the project structure and rules around deployment, so quite impressed after a few years of avoiding it due to how much I hated the song and dance over setting it up.
I'm sure it's less disk space because it has less deps but the most of the RAM and CPU usage in CRA is Webpack so I'd be surprised if that changed much.
webpack AND all the extra plugins and preprocessing and postprocessing CRA adds -- its not a small webpack setup by any means and you can get 1s build times with webpack pretty easily without CRA
Agreed, I use webpack for small and medium projects and it's basically instant. I use TS but not the compiler - I tell babel to strip types and use just a few plugins, transforms and loaders.
I'm not in love but it's a core tool in almost all of my projects, personal and professional.
