Is it correct that the IR bundle size is around 40...

# javascript

[Rescribet]

Is it correct that the IR bundle size is around 4000 lines or am I missing a DCE flag? (jsBrowserProductionWebpack)
There are 22 lines in the bundle which are actually related to Shape which on their own just work as expected (47kB vs 600 byte)

@JsExport
data class Shape(val type: String, val sides: Int)

[Rescribet]

Bundle after human tree shaking, which seems excellent

(function (root, factory) {
  if (typeof define === 'function' && define.amd)
    define(['exports'], factory);
  else if (typeof exports === 'object')
    factory(module.exports);
  else
    root['ir-enumclasses'] = factory(typeof this['ir-enumclasses'] === 'undefined' ? {} : this['ir-enumclasses']);
}(this, function (_) {
  'use strict';
  function Shape(type, sides) {
    this._type = type;
    this._sides = sides;
  }
  Shape.prototype._get_type__0_k$ = function () {
    return this._type;
  };
  Shape.prototype._get_sides__0_k$ = function () {
    return this._sides;
  };
  Shape.$metadata$ = {
    simpleName: 'Shape',
    kind: 'class',
    interfaces: []
  };
  Object.defineProperty(Shape.prototype, 'type', {
    configurable: true,
    get: Shape.prototype._get_type__0_k$
  });
  Object.defineProperty(Shape.prototype, 'sides', {
    configurable: true,
    get: Shape.prototype._get_sides__0_k$
  });
  _.Shape = Shape;
  return _;
}));

[Big Chungus]

Well kotlin needs to put in some of its runtime and stdlib in any app, so initial bundle size will always be substantially bigger than plain-js app. It is especially noticeable for tiny projects, but becomes less so as your app grows.

[Rescribet]

That’s understandable, but those features aren’t used referenced in the exported code (hence manual trimming works, but terser doesn’t seem to be that smart).
The use-case I’m targeting is writing libraries to be consumed by JS/TS rather than a standalone app

[Big Chungus]

DCE has improved since the introduction of IR backend, but it's still far from perfect. I'm affraid bundles will remain bloated until kotlin ships es6 support, which in turn will allow webpack to treeshake resulting js code properly.

[Big Chungus]

For now, I'd stay away from kotlin/js if you aim to write js/ts libs for the browser.

[Rescribet]

Thanks for the feedback. Kinda-sorta expected as much, hopefully it’ll get focus again in the next roadmap update.

[Gabriel Duncan]

anyone know when es6 support will be added?

[Big Chungus]

Nope. I think it's suspended on the roadmap

[Gabriel Duncan]

ugh

[Gabriel Duncan]

we have a production app in kotlinjs. IR helped but i was hoping progress would be good on es6. this makes me think it might be time to refactor to ts. do you have a sense for whether the js target is going to continue to be supported or not

[Big Chungus]

Js target is definitely not going away anytime soon. My guess is that es6 is postponed to focus on stabilising ir backend, which will speed up future mpp kotlin feature development when done.

[Big Chungus]

Even with the current state, I still wouldn't switch apps (not libs) to ts, because bundle size hit is basically one off constant increase which becomes more marginal as your app grows

[Big Chungus]

Then when es6 comes, it'll suddenly become a tad smaller (assuming big app)

[Gabriel Duncan]

that’s helpful. thanks

[Gabriel Duncan]

my blood pressure went down a little

[Rescribet]

For large apps with high requirements, it’ll also depend on whether features like dynamic imports are supported, which can have tremendous impact on performance

[Big Chungus]

You can do dynamic imports with kjs already, you just need to define your own external fun import(module: String): Promise<dynamic>

[Gabriel Duncan]

And what does that import function do? Does that just restrict what gets into the bundle?

[Gabriel Duncan]

Could you give an example?

[Rescribet]

@Gabriel Duncan It somewhat like regular imports, but are resolved run-time. So webpack can keep that code in a separate file. The initial transfer size will be smaller, and thus can be executed sooner, but may cause more requests depending on code paths.
There’s loads of articles on dynamic imports online, but note it can often be a premature optimisation https://v8.dev/features/dynamic-import

[Gabriel Duncan]

thanks @Rescribet. this is super interesting