This is just me arbitrarily assuming things, so I ...

# javascript

[Edoardo Luppi]

This is just me arbitrarily assuming things, so I might be completely wrong.
With the incoming transition to using an external JS downleveling tool (e.g., SWC, Babel, etc.), the K/JS compiler backend could be simplified as it doesn't have to consider many options related to the ES targets anymore, or related to the module systems. That is, the compiler could simply emit ESM ES20xx code and delegate the translation to CJS/UMD/etc. and older ES versions to the external tool. This also means if Kotlin sets some baseline options (e.g., ESM + ES2020), and the developer doesn't need to change that baseline, the external tool could be skipped entirely. Theoretically it means compilation speed, especially during development, could get a lot better.

Edit: tho I'm still ignorant about how the TS type declaration generation will be reshaped.

[Artem Kobzar]

This is exactly the reason for doing the work on SWC integration. It simplifies the lives of everyone

[Artem Kobzar]

One of the thing, I also added to during this SWC integration is a new DSL for compilation, so Kotlin developers should not think about "ES_Something" and think in terms of platforms they need to target.
So there will be the browserslist integration, and people will have posibilities to just say:

targetPlatforms = browserslist("last 2 node major versions")
// OR
targetPlatforms = browserslist(">= 90% in US")

Or to list minimal versions of platforms required for their project

targetPlatforms = minimalVersions {
  chrome = "128"
  safari = "11"
}

[Edoardo Luppi]

That's a neat feature and it aligns to what other frameworks are doing. I already use browserlist with Angular, for example.

(tho there might be situations where an explicit ES target is preferable, especially in a monorepo where the target must be aligned everywhere)

[Artem Kobzar]

Could you please describe the example with monorepo in details? Why is it important to have the aligned ES target there? (especially if the files will be post-processed)

[Edoardo Luppi]

In my case I have a mixed Kotlin + TS monorepo which builds project to be executed on VS Code (Node), where I have 2 build strategies:
1. the development strategy, where every library - be it Kotlin or TS - is compiled using ES2020 (well Kotlin only has 2015, but you get the idea), without bundling or post-processing in general. This is what we use to obtain fast feedback cycles since we need to restart often.
2. the production strategy, where we add bundling on top. Here we might not care about the explicit ES version, but it's still easier to mentally map available features in the VS Code's Node version via those ES versions. I use https://node.green

[Edoardo Luppi]

For webviews, which are built using Angular, we don't care about the ES version. We simply specify the minimum Chromium version via browserlist, that we get from the Electron release notes.

[Edoardo Luppi]

I could probably use the browserlist or minimalVersions approach, but then it would differ from what we use with TS via tsconfig, where we have "target": "es2020"