Actually most webpack config guides also recommend you to start Typescript checker in separate thread(there is plugin for that) and don't block compilation(transpile mode).
But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.
I still don't get it. If I assume that Typescript compiler is the slowest component in the build pipeline, and run it in a separate thread, that still means I have to wait for the tsc to complete. There is little to no benefit in all the other stuff being finished faster; that will be optimizing the 5%, while my main time is wasted in the 95% of the tsc compiler process. At least to my experience, for sufficiently large projects, tsc becomes super slow.
> that still means I have to wait for the tsc to complete
Without fork it. the webpack need to wait the checker to finish checking everything before it compiles even just one file.
With a separate checker, it don't.
The ts-loader will eject a perfectly normal js file without caring the typing is valid or not. And webpack can do the rest of works as quick as possible.
It like different of do it in serial and do it in parallel. The latter will utilize the resources better although not absolutely more efficient.
But even you do this, the speed of webpack still isn't comparable to vite. Because vite don't really scan and bundle the whole node_modules before send browser anything. It leverage the native es module and on demand loading to allow it to 'compile as you need' and give you better startup time and reload time.