I've just run into this tool: https://esbuild.github.io/ It may be a huge win to integrate Kotlin/JS with it instead of webpack...

A new js build tool comes up every month. Webpack is the most stable and widely used so it makes sense for kjs to utilise it under the hood as that allows the team to spend more time working on actual kjs improvements rather than js bundler integrations IMHO.

By that logic we shouldn't have switched to yarn

I'm not saying we should not switch. My point there was that it does not make sense to focus on it now (given all the other issues with kjs).

But are the issues those which occupy people who work on the build part?

I assumed it would though as webpack is part of the build process (no idea how small/big kjs team is). Regardless, the bigger issue with this is how to choose which js bundler to switch to since there are tons.

The compiler backend? The frontend is what's slow. The backends are all pretty quick I think.

Compiler as a whole. Basically everything that's not gradle nor webpack when you run

gradle assemble

I suspect the work on the new frontend will yield the most gains there and that's across all backends, not just JS

My point exactly. Focus on compiler until there are no more significant gains to get. Then look into gains outside of it (e.g. switching out to faster bundlers)

But those are built by different people

For now ppl can bundle raw kotlin js outputs with whatever bundler they like themselves (not trivial to setup, but definitely doable)

The people working on FIR are not the people working on ES2015 are not the people working on the build system

Focus on compiler until there are no more significant gains to get.

I agree basically... but developing the compiler is a very complex and time consuming job. (Just look at the development of K2...) At least I think that replacing the JS bundler is a way much simpler task, and gaining 100x speed-up relative to webpack may be worth the effort...

The old kotlin frontend plugin had a way to switch bundlers, I believe the initial versions came with a way to configure webpack and rollup. That being said, I think the bundling process should be abstracted away so that people can use different bundlers in their tool chain. Example, there was a time when webpack was the goto bundler, now its vite, and tomorrow, it might be something else Building an adaptable build tool chain will make it easy to adopt new bundlers and leverage build times

A new js build tool comes up every month.

that may be true but its also true that vite has emerged as the standard that everybody uses. nobody in the js ecosystem uses webpack. so switching to vite would be a very sensible thing imo

nobody in the js ecosystem uses webpack

Wow, things are moving very fast :)