I've just run into this tool: <https://esbuild.git...

# javascript

[Norbi]

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...

[Big Chungus]

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.

[jw]

By that logic we shouldn't have switched to yarn

[Big Chungus]

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).

[jw]

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

[jw]

Upgrading to ES2015 (can't believe I have to say upgrading for that) isn't going to be done by the same people who would overhaul the build

[Big Chungus]

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.

[Big Chungus]

Also I think webpack consumes minority of the total build time so focusing on kjs transpiler probably has more potential gains. I have no data to back this claim, so do correct me if you do.

[jw]

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

[Big Chungus]

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

[jw]

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

[Big Chungus]

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)

[jw]

But those are built by different people

[Big Chungus]

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

[jw]

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

[Norbi]

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...

[andylamax]

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

[christophsturm]

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

[Norbi]

nobody in the js ecosystem uses webpack

Wow, things are moving very fast :)